libtool
[Top][All Lists]
Advanced

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

Shared library depending on a convenience library


From: Bjarne Vestergaard
Subject: Shared library depending on a convenience library
Date: Mon, 10 Jul 2006 22:03:09 +0200
User-agent: KMail/1.9.1

Hi,

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.

My question is then: How come the convenience library doesn't include 
references to at least the generated .lo files? 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.

Or does anyone know if there is a better way of doing what I'm trying to do?

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 

This will build .lo files, but they'll not be used/referenced anywhere.

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?

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.

Furthermore, I've seen the following text in the libtool documentation:

"If you omit both `-rpath' and `-static', libtool will create a
convenience library that can be used to create other libtool libraries,
even shared ones.  Just like in the static case, the library behaves as
an alias to a set of object files and dependency libraries, but in this
case the object files are suitable for inclusion in shared libraries."

From what I understand, this is essentially what I'm trying to do. But then 
the next sentence states:

"But be careful not to link a single convenience library, directly or
indirectly, into a single program or library, otherwise you may get
errors about symbol redefinitions."

This brings up another question. I'm aware of how one may end up with symbol 
redefinitions, but isn't this sentence in conflict with the statements 
preceding it saying that convenience libraries can in fact be used to create 
shared libraries?

Best regards,
Bjarne Vestergaard




reply via email to

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