Re: Sticky --disable-shared

[Ralf Wildenhues]

* Alessandro Vesely wrote on Tue, Sep 23, 2008 at 03:35:10PM CEST:
> Ralf Wildenhues wrote:
>> * Alessandro Vesely wrote on Mon, Sep 22, 2008 at 07:26:09AM CEST:
>>> yesterday I compiled three packages, libgcrypt, gnutls and 
>>> courier-mta, that use one another's library.
>>
>> FWIW, I didn't fully understand your setup.  But if libraries depend
>> upon each other, then it is typically not possible to build some of them
>> static and some of them shared.  At least most systems disallow shared
>> libraries depending upon nonshared (more precisely: non-PIC) code.
>
> Why not? I can build a shared library linking it with a static one. The 
> static library has to be compiled with -fPIC, of course. It will then be 
> included in the shared one, without further runtime dependencies.

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.

>>> A command line  like "gcc ... -lgcrypt ...", reversing libtool's hard 
>>> path, succeeded.  
>>
>> This, too, can point to a number of reasons.  The author could have
>> ordered them wrongly on the command line, for example.
>
> Yes, the point was argument ordering: I repeated the build and noticed  
> that I also have to rearrange args putting -L/usr/local/lib near the  
> beginning and -lgcrypt near the end. After the "gcc..." command  
> succeeded, I prepended "/bin/sh ../libtool --tag=CC --mode=link" to it  
> and it succeeded again! 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).

>>> I think static libraries are probably safer in this case, where each  
>>> package has a different version.
>>
>> Again, I don't fully understand what you mean with "different version":
>
> 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?
Is that relevant for gnutls, have you measure that?  If yes and yes,
are they using hidden visibility (if no, then please try it), and if
that is also already done, why did they design the library in a broken
way?[1]

Or do you mean you cannot have two versions of the shared library
installed in parallel?  Then, consider installing it under a different
prefix, and all packages that need it, too.  If the .la files are
installed, libtool will add suitable run paths for you, otherwise you
may have to do that yourself.

Cheers,
Ralf

[1] One should provide interfaces that do not require to go through
the indirection very very often, like once for every character or so
(example: fputc vs. fputs).