Subject: AIX again
To: None <email@example.com>
From: Michael <firstname.lastname@example.org>
Date: 08/22/2004 14:16:40
I did some more hacking, even tried to tackle libtool, but - frankly -
hacking a huge shell script is a pain in the butt, so I tried to find a
way around it.
libtool with AIX support can't link shared libraries with static
libraries - it includes them in the export list but silently drops the
reference in the actual linker command - looks like it is confused by
the fact that AIX .a files can contain shared or static objects for
lots of different platforms. And to make things worse it writes wrong
.la files - they refer to the .so file, not the .a file so loading them
through ltdl fails.
A possible workaround:
use plain .so files and a dumb libtool without AIX .a lib support (
like the one that comes with pkgsrc right now ). This allows libtool to
run unchanged, the problems above would just go away and so we can
avoid hacking it. This would look weird because usually you encapsulate
all libraries - shared or not - in a .a file on AIX, but this isn't
enforced. The runtime linker doesn't really care what it loads, if it's
a .a file it unpacks it and picks one or more suitable shared objects,
if it's a .so it just loads it. The only program which is picky about
that is ld, but with a few command line options it can be persuaded to
act almost like an ELF linker - it even supports lazy loading ( load a
shared object not on startup but when it's actually called. Works only
for objects that export only functions though )
Problem with this: at least on AIX 4.3.2 the linker doesn't default to
'dynamic mode' - contrary to IBM's manual - and so it ignores .so
files. I hacked libtool to always include -Wl.-bdynamic -Wl,-brtl when
linking a shared library (that was easy enough to find), seems to work
fine but is ugly - the compiler should take care of that, so I had a
look at gcc... 3.3.4 finally compiles on AIX ( just let the C++ library
configure script run ( well, crawl would be more epropriate ) for ages,
this time it will actually finish, didn't get it to compile in pkgsrc
though ) and found the place where it builds the command line for ld,
added -bdynamic and -brtl for -shared - I hope it will work.
Benefits of the whole thing:
we don't need any special handling for AIX libraries anymore, only a
compiler that forces the linker into dynamic mode and enables runtime
linking, which would be a tiny patch in a single file.
- ld sees only .so files, not .so.4.5.6 but that shouldn't be really
problematic since all packages I've seen so far add a link for that
- no support for multiple architectures in the same library - shouldn't
really be a problem though
- loading takes longer because the runtime linker actually does
something - may be masked by using lazy linking by default.
- there might be libtools that try to build .a files for shared
libraries - more confusion but it shouldn't really hurt
- there might be packages that call ld directly to build shared
libraries - these won't work if they don't know AIX, but the only
packages I can think of doing that are apache1, Python, Perl and PHP -
they all know how to handle AIX.
- binaries shouldn't be stripped - programs like xmms and gaim use
loadable modules which import symbols from the main binary.
Static libraries shouldn't be affected since they aren't build by ld.
Since building gcc on my box takes bloody ages ( well, actually it's
the configure script for the C++ library which bogs everything down,
not the compiler which is pretty speedy ) I don't know if my gcc hack
works - I'll know tomorrow or so, hopefully.