libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sticky --disable-shared


From: Ralf Wildenhues
Subject: Re: Sticky --disable-shared
Date: Mon, 22 Sep 2008 22:55:38 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hello Alessandro,

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

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

> 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":
different packages normally have different versions, because their
versioning is not related, no?

Anyway, static libraries are in no way better suited for version
compatibility issues than shared ones.  Nowadays on modern systems you
will have more problems with static libs.  So just build them all
shared.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]