Re: shared libraries and runtime linking on aix >= 4.2

[Michael Haubenwallner]

On Wed, 2008-03-19 at 01:03 -0500, Peter O'Gorman wrote:
> Michael Haubenwallner wrote:
> > Hi,
> 
> Hi Michael,
> 
> There are quite a few oddities with AIX and libtool, some of them should
> be relatively simple to fix.
> 
> > 
> > Without "-brtl":
> > *) static is disabled when shared is enabled.
> > *) libLib.so.1 is built using 'gcc -shared'
> > *) libLIB.so.1 is packed into libLIB.a.
> > *) this can provide some kind of 'soname' support.
> 
> The soname support would only come if, at install time, the new shared
> object was added to the archive if one already existed at the install
> location, correct?

Shouldn't this be the other way round - add the old shared object (after
'strip -e') to the new archive (this is how gcc suggests) ?

>  This would break DESTDIR installs on AIX (assuming
> that they are not already broken), and would make an 'uninstall' target
> a little harder too :)

Can't see yet how this breaks DESTDIR installs, as the binary package
manager is responsible to merge things found in DESTDIR to live
filesystem...

And doing an uninstall (without DESTDIR) on Linux does not restore the
symlinks to the old soname library - does it ?

> 
> > 
> > With "-brtl":
> > *) static is enabled (into libLIB.a)
> > *) libLIB.so.1.2.3 is created using 'gcc -shared -Wl,-G'
> > *) symlink libLIB.so.1 -> libLIB.so.1.2.3 is created
> > *) symlink libLIB.so -> libLIB.so.1.2.3 is created
> > *) missing kind of 'soname' support.
> > 
> > One problem is the missing kind of 'soname' support with enabled -brtl.
> 
> Yes, the linker encodes the name of the library it found at static link
> time into the output, and that is always, with -lfoo, going to be
> libfoo.so. Possible that we could change the versioning type to be
> foo.N.so and pass -lfoo.N to the linker, which would "solve" that issue.
> That might be doable, but also, ick.

This would only work when doing subsequent links with libtool too -
which is not the case always.

> > AFAICT, runtime linking also works with libLIB.so.1 packed into
> > libLIB.a. And the decision wheter one executable uses runtime linking or
> > not can only be done when linking that executable with/out -brtl.
> > To allow shared libraries to use runtime linking (link with "${wl}-G")
> > does not imply an executable linked against it does use runtime linking.
> 
> The documentation seems to agree with you, from the way I read it we
> should always create shared libraries with -Wl,-G on AIX. Thanks.
> 
> There are problems, however, with undefined symbols when runtime linking
> is not in effect, aren't there? A quick (probably too simple) test on
> AIX-5.3 shows this (sorry for wrapping, some libtool output removed,
> used libtool-1.5.24 because it was handy):

It is still possible to pass "-bernotok" after "-G" to ld to have it
bailing on undefined symbol 'mainly'.

Currently, when simply building without any additional flag to libtool,
this testcase can be built successfully, but dumps core on execution,
even if -brtl is enabled when linking main.

Because both 1.5.26 and 2.2 pass -Wl,-berok after the export list,
unless '-no-undefined' is passed. So even without "-Wl,-G" unresolved
symbols are allowed by default.
OTOH, because runtime linking is not enabled by default, one could call
this 'broken' or at least 'inconsistent'...

(btw, this is why I always add '-brtl' in my ld-wrapper currently)

With 2.2:
$ libtool --mode=link --tag=CC gcc -o libbaz.la baz.lo -rpath /foo 
-Wl,-G,-bernotok
libtool: link: gcc -shared -o .libs/libbaz.so.0  .libs/baz.o   -lc 
-Wl,-bnoentry  -Wl,-G -Wl,-bernotok   -Wl,-bE:.libs/libbaz.exp -Wl,-berok

With 1.5.26 (seems like some quoting/eval bug, although it works):
$ libtool --mode=link --tag=CC gcc -o libbaz.la baz.lo -rpath /foo 
-Wl,-G,-bernotok
gcc -shared -o .libs/libbaz.so.0  .libs/baz.o  -lc -Wl,-bnoentry  -Wl,-G 
-Wl,-bernotok -Wl,-bE:.libs/libbaz.exp ${wl}-berok

> % ./libtool --mode=link --tag=CC xlc -o libbaz.la baz.lo -rpath /foo -Wl,-G

Withoug '-berok', libbaz.la cannot be fully linked. Ok so far, System V
behaviour is like linking with '-G'. And a shared library relying on
external symbols cannot be linked without -berok on AIX.

> % ./libtool --mode=link --tag=CC xlc -o main main.lo libbaz.la -Wl,-brtl

But then, another package 'main' using 'baz' needs to know that it must
enable runtime linking to have 'baz' work as expected.

Another point:
Many open source packages are developed/tested on some Linux, and
libtool often is used to avoid porting the build mechanism to other
platforms. While relying on undefined symbols is some kind of bad
design, it still is the default in System V. And isn't libtool expected
to get this package working on any system (wherever undefined symbols
are possible)? In case the package should run on native windows fex, it
needs to be redesigned to avoid undefined symbols anyway, while it still
works with rtl enabled.
So, why not have libtool enable rtl by default, but allow disabling it
somehow ? Same for 'allow undefined' ?

Thoughts?

Thanks!
/haubi/