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.

> This may as well be a problem with libtool (what a mess that progam is),

libtool is one mighty complicated thing that I willingly admit am far from
mastering.

> or it could be that we're not using it correctly.

I tried to link the lib500 tests the same way the 'curl' executable is linked,
as I thought that was working fine these should work fine too...

Also, since it does work on a bunch of platforms so it can't be completely
wrong.

> I'm still struggling to figure this out. In fact the relinking command for
> lt-curl is also wrong, it just happens to work because of some undocumented
> feature with the AIX ld program (if the ssl calls are in a *library* instead
> of in .o files, then the compile time path (the standard -L.. stuff) is used
> during runtime *anyway*, even if the documentation says its ignored if a
> runtime path is explicitly set.

Hehe, so if we turn the core parts of the lib509 test into a library we can
make it work! ;-)

> Here's some stripped down output from 'sh -x lib509' in the tests/libtest
> directory:
> relink_command=(cd /home/tor/build/cvs-curl/test/tests/libtest; \
> xlc -g -o $progdir/$file lib509.o first.o -L/usr/local/ssl/lib \
> -L../../lib/.libs -lcurl -lssl -lcrypto -lz \
> -Wl,-blibpath:/home/tor/build/cvs-curl/test/lib/.libs:\
> /usr/local/lib:/usr/lib:/lib)
>
> The runtime directory specification is set with -blibpath in AIX, and there
> are two ways of fixing the problem:
>
> 1) Remove -Wl,-blibpath altogether

Yes, but that would make it depend on the undocumented usage of the link path
in run-time.

> 2) Add /usr/local/ssl/lib to -blibpath

I believe this is the correct approach. I can't see how this is not a libtool
bug.

The lib509 is made dependent on the '$(LIBDIR)/libcurl.la' to allow libtool to
find what other libraries it will need to link this. I figure it needs to
convert the info from that file into a proper link line. That file has a
'dependency_libs' field for "Libraries that this one depends upon".

> Libtool has this:
> hardcode_libdir_flag_spec="\${wl}-blibpath:\$libdir:/usr/lib:/lib
>
> so it looks like "$libdir" is replaced with
> /home/tor/build/cvs-curl/test/lib/.libs:/usr/local/lib when the
> libtest/lib509 program is created. But I haven't found out how this
> happens, or where it's set.

'libtool' is created by the configure script and it checks for some basics
before that is done. As your configure output reports:

checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking dynamic linker characteristics... aix5.1.0.0 ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
creating libtool

Then, when lib509 is to be linked it will run a command line that looks
similar to (in my case here the ssl and crypto libs are present in /usr/lib):

  /bin/sh ../../libtool --mode=link [CC] [CFLAGS] [LDFLAGS] -o lib509 \
  lib509.o first.o ../../lib/libcurl.la -lssl -lcrypto -ldl -lz

In your case the complete command line looks like:

  /bin/sh ../../libtool --mode=link xlc -g -g -L/usr/local/ssl/lib -o lib509 \
  lib509.o first.o ../../lib/libcurl.la -lssl -lcrypto -lz

If you ask me, libtool should use the given input arguments and create a
working output file. It should set the proper options for it to work. If not,
it bugs. This command line and known architecture specifics should be enough
and it seems to be so on so many (other) platforms.

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!

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...)

-- 
     Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
      Dedicated custom curl help for hire: http://haxx.se/curl.html