Re: Sticky --disable-shared

[Ralf Wildenhues]

* 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