[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sticky --disable-shared
From: |
Alessandro Vesely |
Subject: |
Re: Sticky --disable-shared |
Date: |
Tue, 23 Sep 2008 15:35:10 +0200 |
User-agent: |
Thunderbird 2.0.0.16 (Windows/20080708) |
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
- Sticky --disable-shared, Alessandro Vesely, 2008/09/22
- Re: Sticky --disable-shared, Ralf Wildenhues, 2008/09/22
- Re: Sticky --disable-shared,
Alessandro Vesely <=
- Re: Sticky --disable-shared, Brian Dessent, 2008/09/23
- Re: Sticky --disable-shared, Bob Friesenhahn, 2008/09/23
- Re: Sticky --disable-shared, Ralf Wildenhues, 2008/09/23
- Re: Sticky --disable-shared, Alessandro Vesely, 2008/09/24
- Re: Sticky --disable-shared, Ralf Wildenhues, 2008/09/25