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) _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
