Re: RFC: on AIX, which "soname"-equivalent to prefer with runtime linking?

[Michael Haubenwallner]

On 01/22/11 17:41, Peter O'Gorman wrote:
> On 01/21/2011 08:19 AM, Michael Haubenwallner wrote:
>> Hello!
> 
> Hi.
> 
> Library versioning for AIX would be a great feature.
> 
>>
>> After playing around with different ways[1], this is my proposed one,
>> using an AIX feature called "Import Files":
>>
>> *) Create the shared object "shr.o" (using '-G' linker flag).
>> *) Set the LOADONLY flag for "shr.o" (using 'strip -e').
>> *) Create the Import File "shr.imp", containing
>>     - this header:
>>         #! libNAME.so.1(shr.o)
>>         # autoload
>>         #! libNAME.so.1(shr.o)
>>     - the list of symbols exported.
>> *) Create the archive library "libNAME.so.1.2.3" from both
>>     "shr.imp" and "shr.o".
>> *) Create the symlinks as usual:
>>     libNAME.so.1 ->  libNAME.so.1.2.3
>>     libNAME.so ->  libNAME.so.1.2.3
>>
>> Using this way, for existing packages it might be necessary to give the
>> package manager the choice whether to "--enable-aix-soname", or to keep
>> the old way the package used to create "libNAME.so" before.
> 
> If I upgrade a library from say version 1.2.3 to 1.2.5, with both having the 
> same libtool version information,
> but with 1.2.3 linked with the current -brtl libtool system, and 1.2.5 using 
> your proposed method,
> will clients of the library still work?

(assuming 1.2.5 is binary compatible to 1.x, the soname (on Linux) is 
libNAME.so.1,
while version 2.0.0 is incompatible and does have soname libNAME.so.2)

Currently, subsequent executables require "libNAME.so" to be a standalone
shared object. When using the new way, "libNAME.so" is (a symlink to) an
archive file.

The simple answer is: No.

However, when upgrading to version 2.0.0, existing binaries will be broken
anyway, even with the old way where "libNAME.so" is the shared object.
Unless you --enable-aix-soname even for version 1.x, you are unable to upgrade
to 2.0.0 without breaking existing binaries, even when keeping the old shared
object around somewhere.
So in both cases, either enabling aix-soname or upgrading to 2.0,
you have to rebuild the reverse dependencies anyway.

This is the reason why the package /manager/ has to have the choice whether
to --enable-aix-soname or not, as only she may have control over the packages
currently linked against that "soname" of the library.

OTOH, when the package /maintainer/ does a soname bump, she might want to
force the aix-soname without leaving the choice to --disable-aix-soname,
as existing binaries using this libraries will break anyway.

> 
>>
>> The reasons to choose this way:
>>
>> *) It is possible to dlopen() with or without a version number:
>>     - dlopen("libNAME.so(shr.o)", RTLD_MEMBER), besides the preferred
>>     - dlopen("libNAME.so.1(shr.o)", RTLD_MEMBER), and even
>>     - dlopen("libNAME.so.1.2.3(shr.o)", RTLD_MEMBER) does work.
> 
> Does dlopen("libNAME.so", RTLD_GLOBAL|RTLD_NOW) (for example) without 
> RTLD_MEMBER work?
> 
> Do you currently have patches for libtool, or do you want pre-approval before 
> working on them?
> If you have any, even if only half finished, I would like to see them.

For the last few years, I've played around with different ways here to learn
which way could be the best one.
While the patches I currently have do provide shared library versioning, they
do not do this proposed way yet. Unfortunately, they do not create the soname
libNAME.so.1 as symlink to an archive file, but as standalone shared object,
while libNAME.so is the symlink to an archive file containing the import file.
Additionally, they do force -no-undefined ATM.

And yes, I'd like to have some commitment now upon /how/ I break all my
packages on AIX once again.

Anyway, you've asked for half finished patches:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/ELT-patches/aixrtl/

/haubi/