[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shared library depending on a convenience library
From: |
Ralf Wildenhues |
Subject: |
Re: Shared library depending on a convenience library |
Date: |
Mon, 10 Jul 2006 22:45:37 +0200 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
Hello Bjarne,
* Bjarne Vestergaard wrote on Mon, Jul 10, 2006 at 10:03:09PM CEST:
>
> I've been trying to use libtool to build a shared library that depends on a
> libtool convenience library. But for some reason, the convenience library
> that I've created doesn't contain any reference to .lo or .so files. When
> linking the shared library, it will therefore contain a TEXTREL member in the
> headers. This signifies that one or more relocation entries might request
> modifications to a non-writable segment. I'd like to avoid this.
Shouldn't happen. Please print the output of these commands...
> I'm using libtool 1.5.22 with GCC on Linux (i686). The way I created the
> convenience library is as follows:
>
> libtool --mode=compile gcc -c libB.c -o libB.lo
> libtool --mode=link gcc libB.lo -o libB.la
... as well as the output of
libtool --features
libtool --config
I assume the libtool you're using has been configured with
--disable-shared or so.
> My question is then: How come the convenience library doesn't include
> references to at least the generated .lo files?
It should include all PIC objects in an (.a) archive.
> I would guess that if they
> were referenced in the convenience library, the shared library could in
> principle be linked directly against the .lo files and hence avoid the
> TEXTREL member in the headers of the shared library.
That's exactly what's supposed to happen.
> I've seen one post from Ralf Wildenhues (Re: how to use circular
> dependencies,
> Thu, 11 Aug 2005) saying that:
>
> "Libtool currently has the limitation that it does not build two convenience
> archives, one with PIC and one with non-PIC code, when both types of libs are
> to be built."
>
> So perhaps I simply ran into (a derivative of) this limitation?
No. The limitation here is that static libraries that depend upon a
convenience archive may also get some PIC objects. This is suboptimal,
but not a problem most of the time.
> Another post from Ralf (Re: exclusive static or shared, Fri, 17 Feb 2006
> 20:14:13) says that:
>
> "First, don't let shared libraries have static libraries as dependencies.
> It's a pain, there are many systems where this will not work as desired,
> and making sure you never end up with duplicate symbols and/or arising
> subtle bugs is not easy."
>
> Which is another motivation for why I'd like to have my shared library linked
> against the .lo files instead of the static library.
Right.
Cheers,
Ralf, (don't wait for my next answer)