[0/21] Add support for AIX 6

Richard Sandiford richards@transitive.com
Tue Mar 10 13:58:00 GMT 2009


This series of patches adds support for AIX 6.  In truth, only one patch
is actually specific to version 6; the rest fix problems with the existing
AIX 4 and AIX 5 code.  The aim of many of the patches is to resolve the
failures mentioned in the following libtool message:

*** Warning: the GNU linker, at least up to release 2.9.1, is reported
*** to be unable to reliably create shared libraries on AIX.
*** Therefore, libtool is disabling shared libraries support.  If you
*** really care for shared libraries, you may want to modify your PATH
*** so that a non-GNU linker is found, and then restart.

With some libtool and gcc patches, a cross toolchain produced good
GCC testresults, and we've been able to use it in-house to build our
applications.  (The build includes both shared libraries and executables.)
I'm sure there are other issues that I haven't fixed here though.

One of the big issues was: how should we handle archives and symbol
resolution?  On AIX, it is possible to link dynamically against both
shared objects _and_ archives that contain shared objects.  The latter
are more commonly used.  For example, whereas GNU systems have a separate
shared C library (libc.so.X) and static-only archive (libc_nonshared.a),
AIX has a single libc.a that contains both the shared object and the
static-only objects.

This causes problems with things like:

   gnu-ld bar.o -lfoo frob.o

in cases where the user is expecting "foo" to be a shared library.
The executable should link dynamically against foo regardless of
whether foo appears to be needed; you would use:

   gnu-ld bar.o --as-needed -lfoo --no-as-needed frob.o

if you wanted "foo" to behave more like an archive.  However, if shared
library "foo" _is_ an archive, the first command behaves like the second.
You would need:

   gnu-ld bar.o --whole-archive -lfoo --no-whole-archive frob.o

to get the normal ELF behaviour.

This means, for example, that:

   gnu-ld ... -lpthread ... objects ...

fails with a shared libpthread.a, but:

   gnu-ld ... objects ... -lpthread ...

works.

Now the AIX linker appears to apply something like --whole-archive
semantics to _all_ archives.  So, for example:

----------------------------------------------------------------------
#!/bin/bash
set -eu
cat <<EOF > a.c
int x = 1;
EOF
cat <<EOF > b.c
int x = 2;
int main (void) { return x; }
EOF
gcc -c a.c -o a.o
rm -f libfoo.a
ar rc libfoo.a a.o
gcc -L. -lfoo b.c
./a.out || echo $?
rm -f a.out a.c a.o b.c libfoo.a
----------------------------------------------------------------------

prints "2" on your typical ELF target, and on AIX when using the
GNU linker.  But when using the native AIX linker it produces:

----------------------------------------------------------------------
ld: 0711-224 WARNING: Duplicate symbol: x
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
1
----------------------------------------------------------------------

This means that "ld -lpthread ..." works as expected when using the
native linker.  However, the knock-on conseequences might surprise some
users if we did the same thing in the GNU linker.

Also, when resolving symbols, the native linker does not care whether
a definition comes from a direct relocatable object, a direct shared
object, or an archive member.  Strong definitions in shared objects
can override weak definitions in the main objects.  If shared object A
comes before relocatable object B, a weak definition in A trumps a weak
definition in B.  A strong definition in A also trumps a strong
definition in B, albeit with a multiple-definition warning.

I couldn't decide whether to make the GNU linker behave like the AIX
linker or not.  In the end, I left things as they are for no other
reason than it's what we've always done.

All patches in the series were tested against the binutils and
gcc testsuites.

As far as copyright goes: I did this work for Transitive after
they were bought by IBM, and my name has been added to the IBM
copyright assignment.  This work is therefore covered by that.

Richard



More information about the Binutils mailing list