* Alessandro Vesely wrote on Wed, Sep 24, 2008 at 11:53:55AM CEST: > Ralf Wildenhues wrote: >> >> Most likely somebody putting libraries in *_LDFLAGS rather than *_LDADD >> (for programs) or *_LIBADD (for libraries). > > In part. For gnutls, the external (possibly static) libraries came > before convenience archives on the command line. I have to quote that > line: > > /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -pipe > -I/usr/local/include -march=nocona -O2 -Wno-pointer-sign -march=nocona > -O2 -o psktool psk-gaa.o psk.o ../lib/libgnutls.la -L/usr/local/lib > -lgcrypt -lgpg-error ../gl/libgnu.la ../lgl/liblgnu.la > > The above failed. It worked after reordering it like so: > > /bin/sh ../libtool --tag=CC --mode=link gcc -L/usr/local/lib -std=gnu99 > -pipe -I/usr/local/include -march=nocona -O2 -Wno-pointer-sign > -march=nocona -O2 -o .libs/psktool psk-gaa.o psk.o > ../lib/.libs/libgnutls.so ../gl/.libs/libgnu.a ../lgl/.libs/liblgnu.a > -lgcrypt -lgpg-error
You should not ever need to add paths that contains .libs to the libtool input line. Since you only post input lines but not the output of them, I can only guess that this should have worked as well, right? /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -pipe -I/usr/local/include -march=nocona -O2 -Wno-pointer-sign -march=nocona -O2 -o psktool psk-gaa.o psk.o ../lib/libgnutls.la -L/usr/local/lib ../gl/libgnu.la ../lgl/liblgnu.la -lgcrypt -lgpg-error If yes, find out where -lgcrypt -lgpg-error came from. They need to be in LDADD not LDFLAGS. Or they can be listed as deps when creating the convenience archive. > Perhaps, since libtool takes care of distinguishing between convenience > archives and installed libraries, it could reorder them correctly. Well, you are not giving libtool the information that the code from the convenience archives needs these libraries, no? >> Then, consider installing it under a different >> prefix, and all packages that need it, too. > > They came naturally in that way, stock debian packages in /usr/lib and > /usr/bin, newer versions in /usr/local/*. OK. >> If the .la files are >> installed, libtool will add suitable run paths for you, otherwise you >> may have to do that yourself. > > Yes, .la's are installed. However, ldd shows no hardcoded path (except > /lib64/ld-linux-x86-64.so.2.) Should I have set hardcode_shlibpath_var > to get that? I have no LD_* env vars, and usually need to run ldconfig > manually after installing home built shared libraries in unusual places. First, ldd is useless for this, use objdump -p. Second, your runtime linker might have /usr/local/lib or /usr/local/lib64 in its default search path (find out! look at ldconfig manpage). If it doesn't, then I really need to see the link command lines (input plus output) and output of './libtool --config' of what you think should have added the run paths but hasn't. Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
