I'm replying to an old thread from 2004.. I was looking into test 509
on AIX again and did a google about a libtool/linking problem.. and
found only our own old thread :-) I had forgotten most of it anyway
and it was useful to combine the old and some new info.

On Apr 23 [2004], 9:56, Daniel Stenberg wrote:
>On Thu, 22 Apr 2004, Tor Arntsen wrote:
>
>> Just a quick note on the failing 509 test for AIX 5.x: The test actually
>> passes, the problem is that the relinking command fails to relink the
>> lt-lib509 program correctly (the runtime path is missing the ssl directory,
>> so 'ldd .libs/lt-lib509' says "Cannot load module libssl.a(libssl.so.0"). I
>> have relinked it manually and the test then passed ok.
>
>Aha. I hadn't really thought about it before, but 509 is the only test in the
>500-series that uses SSL.
>
>> Which means that the 'Test' column for today's autobuilds should really be
>> all green..
>
>That's indeed nice to know.
[...]

To summarize: Test 509 is ok on AIX but the test program fails to find ssl:

http://curl.haxx.se/auto/log.cgi?id=20051208081521-7931
== Start of file stderr509
 Could not load program /build-40412/tests/libtest/.libs/lt-lib509:
 Dependent module libssl.a(libssl.so.0) could not be loaded.
 Could not load module libssl.a(libssl.so.0).
 Error was: No such file or directory
 == End of file stderr509

The libtool generated script passes a -W,blibpath argument to the linking
process, and this screws up the runtime linker path. This is hardcoded
originally in libtool.m4 if AIX, and it's been there for a long time and
is still there in the latest libtool version.
I'm of the opinion that using -Wblibpath the way libtool does is fundamentally
broken. Remove it, and all problems go away afaik. However, that's something
we can't do as it's part of libtool, not curl.

Daniel wrote (back in 2004):
>How come it works for 'src/curl' and not 'tests/libtest/lib509' ? The command
>lines look very similar and they both depend/require/use the same set of
>libraries!

I figured out this too since then.. found out about the 'dump -n' command
and did some testing.

The reason it works for curl and not for lib509 although both are linked
the same way (_with_ -Wl,blibpath) is that curl doesn't reference SSL
directly, only libcurl does. So on AIX one can in fact link the curl binary
without -lssl, it makes no difference. dump -n shows for curl (lt-curl):
INDEX PATH BASE MEMBER
0 /home/tor/build/cvs-curl/test/lib/.libs:/usr/local/lib:/usr/lib:/lib
1 libc.a shr.o
2 libcurl.a libcurl.so.3
3 libz.a libz.so.1
(Note no reference to libssl)

But lib509 *does* reference ssl directly, and it shows:
INDEX PATH BASE MEMBER
0 /home/tor/build/cvs-curl/test/lib/.libs:/usr/local/lib:/usr/lib:/lib
1 libc.a shr.o
2 libcurl.a libcurl.so.3
3 libssl.a libssl.so.0
4 libcrypto.a libcrypto.so.0

libcurl.so.3 on the other hand:
INDEX PATH BASE MEMBER
0 /usr/local/ssl/lib:/usr/lib:/lib
1 libc.a shr.o
2 libcrypto.a libcrypto.so.0
3 libssl.a libssl.so.0
4 libz.a libz.so.1

libcurl.so.3 is created without any -W,blibpath stuff, so the linker
simply includes the -L param (in this case /usr/local/ssl/lib) and we're
fine. So when curl is executed it loads libc, libz and libcurl, and libcurl
looks for libssl and finds it ok.

lib509 tries to look for libssl by itself and fails because of the wrong
path (which -Wl,blibpath inserted).

Unfortunately I don't have a solution for this still, there's no way to
adjust the hardcoded -Wl,blibpath argument in libtool - the only variable
that can be changed is a single $libdir var and that's no use. Can't seem to
get rid of -Wl,blibpath either, at least not for executables unless I
overlooked something.

To me it looks like a libtool problem (as Daniel too concluded in the old
mail I'm replying too) and it's a mess to dive in to. To the libtool
authors' defence it could be argued that AIX linking is a certain kind
of hell all by itself - there are some real horrors there. (E.g. apparently
a shared library that has been used once will hang around all by itself,
_even if no program is currently using it_ - the inode is closed, and _still_
the next program will use that library even after it has been deleted and
replaced and walked over. Shudder.)

>If nothing else, you can try upgrading to libtool 1.5.6 first just to see that
>they haven't fixed this since the 1.4.2 you're using. (I couldn't find
>anything specific mentioned of this particular problem in the libtool
>ChangeLog/NEWS but anyway...)

The autobuilds are now using 1.5.8 and it's still the same (although going
to that version fixed some other libtool problems we had for quite a while).

-Tor
Received on 2005-12-08