Re: Sticky --disable-shared

[Alessandro Vesely]

Ralf Wildenhues wrote:
> In libtool lingo, a static library that is compiled -fPIC is called
> convenience archive.  One key feature of it is that it is not installed,
> as Brian already mentioned.

Yeah, I agree with Brian's and Bob's criticisms, in general. However, 
sometimes it is convenient to temporarily skip correctness.

> > [...] Thus, the possible bug should be somewhere else 
> > in the toolchain (automake or autoconf.)
>
> 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

Perhaps, since libtool takes care of distinguishing between 
convenience archives and installed libraries, it could reorder them 
correctly. (Handling -L and -I correctly may be trickier, and I see no 
reason why libtool would want to do it.)

> > I had a two-years-old shared gnutls library running on that mail server. 
> > The task was building a new version of the mail server using a current 
> > version of gnutls, with minimal latency. Shared libraries cannot allow 
> > that. :-/
>
> Why?  Are you speaking about the overhead implied by GOT addressing?

No. (I see the tendency to daemonize programs to avoid reloading them 
very very often, although with 64bit registers able to handle exabytes 
of data, one could prelink using disk addresses...)

> Or do you mean you cannot have two versions of the shared library
> installed in parallel?

Yes, I needed the newer for building the new software, and the older 
to keep the old software running meanwhile.

> 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/*.

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

Ciao
Ale