[gentoo-alt] [PREFIX] switching to "native" style shared libraries on AIX

[Michael Haubenwallner]

Hi,

(sorry for that long mail - yes, this topic is complex)

First to say: The "native" style of shared libraries on AIX is to pack
some "shared object" into an "archive library" [1].

[1] http://www.ibm.com/developerworks/aix/library/au-gnu.html#N101D9

Using this style, it is possible to have something like what is called
'soname' in most ELF systems.

Currently, most packages create such native style shared libs on AIX in
prefix, while some (system-) packages do not (ncurses, readline, zlib,
bzip2, libperl/perl, openssl, apr/apr-util/subversion, ...).

< the most important in this mail >

        Unfortunately there is no way (currently?) for that system
        packages to _switch_ from linux- to aix-style shared libs on an
        _existing_ AIX EPREFIX for various reasons.

</ the most important in this mail >

Well, AIX (since AIX 4.2) _can_ use 'libX.so', when using linker flag
'-brtl' (feature called "runtime linking")[1], but then there is no such
'soname'-like mechanism, which is a real issue when it comes to major
gcc upgrades, as we will need to provide gcc libs in a standard location
because of minor gcc upgrades [2].

[2] http://archives.gentoo.org/gentoo-alt/msg_4284d1915556e743727e7621f13ef5b9.xml
    http://thread.gmane.org/gmane.linux.gentoo.alt/3430

Thus gcc provides its "shared object" named "libstdc++.so.6" packed into
the "archive library" named "libstdc++.a" on AIX.
As suggested on gcc platform specific site[3], when upgrading from old
gcc, one (human, package managers) can extract "libstdc++.so.5" from old
"libstdc++.a", give it the F_LOADONLY flag, and pack it into the new
"libstdc++.a", to keep binaries built with old gcc still running,
because they have recorded to load "libstdc++.so.5" from "libstdc++.a",
while linking new binaries ignore "libstdc++.so.5" (because of the
F_LOADONLY flag) and link against "libstdc++.so.6".

[3] http://gcc.gnu.org/install/specific.html#x-ibm-aix

OTOH, we eventually want runtime linking like known from linux and other
System-V *nices[1]. I've seen somewhere (can't remember exactly), that
gcc's exception handling works better with runtime linking enabled in
some corner cases. So the ld-wrapper used in prefix currently enables
'-brtl' internally, but this may change in the future...

But now, why do packages not create shared library in "native" style ?

Thing is, *libtool* _does_ create "native" style aix shared libraries
(provided that shared libraries are to be created at all) when there is
_no_ "-brtl" or "-Wl,-brtl" found in LDFLAGS. libtool does not build the
static objects then, because having both static and shared objects of
the same sourcecode in the archive library is a bad idea. I've
experienced that shared object won't be used when there is a static
object providing the required symbols in the same archive library - but
don't trust me on this one.

And yes, gcc uses libtool to create its libraries.

Now, the packages _not_ using libtool mostly create lib.so.1.2.3 along
with the symlinks libX.so.1 and libX.so, as they do on linux.
These packages need to be fixed/ported.

Additionally, there are some packages putting "-brtl" or "-Wl,-brtl"
into LDFLAGS, resulting in libtool also creating libX.so.1.2.3 with
symlinks. The easiest way here eventually is to have libtool ignoring
-brtl in LDFLAGS for whether to create aix style shared libs.

Will create a tracker bug on this issue.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-alt@l.g.o mailing list