On 11/05/2012 07:31 PM, David Edelsohn wrote: > On Mon, Nov 5, 2012 at 1:10 PM, Michael Haubenwallner > <michael.haubenwall...@salomon.at> wrote: > >> Well, as long as the old sharedlibs were not created as standalone shared >> objects (lib.so), this is similar to a normal "soname"-bump on AIX, in that >> it is still possible for the package manager to transfer the old shared >> objects (with F_LOADONLY flag set) into the new archives. > > Yes, the old shared objects can be placed in the new archive, but one > also needs to ensure that the archive has the correct name, e.g. > libfoo.a not libfoo.so.x.y ad libfoo.so.
Actually, AIX does symlink some of its system libraries (including libc), so it seems to be fine when libfoo.a is a symlink to libfoo.so.x.y containing the correct shared objects. >> As far as I can see, gcc does not provide this libtool-option (environment >> variable LDFLAGS=-brtl) at all for its libraries (for good reason). > > I do not understand what you mean by gcc does not provide this libtool > option. GCC does link libstdc++ with -G option, for use with -brtl, > but does not automatically link applications with -brtl. When vanilla libtool detects "-brtl" in LDFLAGS, it does: * Link the Shared Object with -G flag. * The Shared Object's filename is libNAME.so.1.2.3 * Create symlink libNAME.so.1 -> libNAME.so.1.2.3 * Create symlink libNAME.so -> libNAME.so.1.2.3 * Create libNAME.a from static objects. When "-brtl" is not in LDFLAGS, it does it the traditional way: * Link the Shared Object with -bM:SRE flag. * The Shared Object's filename is libNAME.so.1 * Put the Shared Object into libNAME.a The former is what is incompatible with this "aix-soname" proposal, but I've never seen any gcc library (libstdc++) being created that way as standalone Shared Object. Instead, libstdc++ is created the traditional way, but with -G flag - not listening to -brtl in LDFLAGS as vanilla libtool does. /haubi/
