Re: Sticky --disable-shared

[Alessandro Vesely]

Hi Ralf,

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.

I had never used libtool directly until today. Now I know it supports 
those kind of builds.

> > I write to ask if that's a bug or a feature, and if it belongs to  
> > libtool, gcc, or ld. The command "libtool ... -lgcrypt ..." was being  
> > changed to "gcc ... /usr/local/lib/libgcrypt.a ... -Wl,--rpath  
> > -Wl,/usr/local/lib" and resulted in an ld error. (Why?)
>
> Dunno.  Would need at least to see the full command line plus all output,
> in order to be able to say any better.
>
> > 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.)

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

Thanks a lot for your prompt reply
Ciao
Ale