Would you like changes to enable AIX shared libraries to use simpler packaging and support shlib_variant? #21504
Replies: 3 comments 3 replies
-
I think they'd be worthwhile. I'd probably go for the non-default alternative rather than replacing the existing packaging (it's more compatible). |
Beta Was this translation helpful? Give feedback.
-
My company is using OpenSSL 3.0 series (long-term support branch) and eventually we'll want it there. But to start out, which branch should I target for a PR? |
Beta Was this translation helpful? Give feedback.
-
Hm... I do the variant stuff on AIX, it creates the |
Beta Was this translation helpful? Give feedback.
-
Reading the discussion guidelines, I'm not sure this fits primarly as a discussion or an issue. I'd welcome feedback. If it's favorable, I can file an issue and a proposed fix.
AIX shared libraries can be packaged two ways:
libxxx.a(foo.o)
: wherefoo.o
is a shared object (this was the original support and the only option for some number of AIX releases)libxxx.so
(supported for several years now on supported AIX releases)Shared libraries that depend on other libraries get their embedded dependency recorded based on how the linker found the library. Example: if
foo.o
depends onlibY.a(bar.o)
, and is created with a link step that uses-lY
, then the runtime dependency insidefoo.o
is tolibY.a(bar.o)
. Whenfoo.o
is packed into the archive, thenlibX.a(foo.o)
has a dependency onlibY.a(bar.o)
. IflibX.so
depends onlibY.so
, and is created with a link step that uses-lY
, then the runtime dependency insidelibX.so
is tolibY.so
.OpenSSL builds AIX libraries as:
libssl.a(libssl.so)
: shared library in an archivelibcrypto.a(libcrypto.so)
: shared library in an archivelibssl_a.a
: static librarylibcrypto_a.a
: static libraryFor OpenSSL, libssl depends on libcrypto, and is created by a linker command using
-lcrypto
. The shared object for libssl will have an embedded reference tolibcrypto.a(libcrypto.so)
.This all works OK with the OpenSSL builds until you attempt to configure a shlib_variant.
The OpenSSL model as I understand it is that for shlib_variant builds, the applications can still use the same include file names and link with
-lssl -lcrypto
, but the embedded references will be to the shared objects' variant names, such aslibssl-foo.so
andlibcrypto-foo.so
on other platforms. You only need to install the variant-named libraries to get a working application.On AIX, shlib_variant OpenSSL builds produce shared libraries like this (with variant "-foo"):
The application can link
-lssl -lcrypto
, but the runtime dependencies are a mixture of variant and non-variant names. The containing archive name (libcrypto.a
) is used for the reference, and thus you have to install the archive library with its original name (libcrypto.a
). [Or, not supported by the build system, an administrator could modify an existing (system) library archive of the same name to add the variant-named shared object as an archive member. I wouldn't recommend this, since it modifies some other package's files!]The application depends on
libssl.a(libssl-foo.so)
andlibcrypto.a(libcrypto-foo.so)
.If you try to cure the need for non-variant named archive files after an OpenSSL build, by renaming the shared library archives, to get these files/contents:
it only half-works when linking an application. The application can be linked
-lssl-foo -lcrypto-foo
, and has embedded references tolibssl-foo.a(libssl-foo.so)
andlibcrypto-foo.a(libcrypto-foo.so)
.But
libssl-foo.a(libssl-foo.so)
has a dependency on the shared library in the original archive name seen whenlibssl-foo.so
was linked, namelylibcrypto.a(libcrypto-foo.so)
. That means you still have to installlibcrypto.a
onto the target. That breaks (for us) the model of wanting to install libraries only with file system names likelibcrypto-foo.a
.Rather than deal with all the hassle of a shared object inside an archive, we can instead change the way OpenSSL packages libraries on AIX to use a shared object.
There's a way to create files such that
libssl.so.3
has a runtime embedded dependency onlibcrypto.so.3
:libssl.so
: a link-import library that refers to libssl.so.3 (some simple scripting can create this during a build)libcrypto.so
: a link-import library that refers to libcrypto.so.3libssl.so.3
: the shared librarylibcrypto.so.3
: the shared libraryTo link applications, you need both the
.so
and the.so.3
for each library. For example, when linking with-lcrypto
, the linker processeslibcrypto.so
, sees its reference tolibcrypto.so.3
, and creates the application with a runtime library dependency onlibcrypto.so.3
.At run time, the application directly references
libssl.so.3
andlibcrypto.so.3
.libssl.so.3
itself referenceslibcrypto.so.3
.With this build style, shlib_variant now works OK. You get:
libssl.so
: link-import library that refers tolibssl-foo.so.3
libcrypto.so
: link-import library that refers tolibcrypto-foo.so.3
libssl-foo.so.3
: the shared librarylibcrypto-foo.so.3
: the shared librarylibssl.a
: static librarylibcrypto.a
: static libraryAt link time you still specify
-lssl -lcrypto
; at run time you only installlibssl-foo.so.3
andlibcrypto-foo.so.3
.So, I can contribute changes to enable this style of shared library support on AIX.
Beta Was this translation helpful? Give feedback.
All reactions