[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 

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


Ralf, (don't wait for my next answer)

reply via email to

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