[Top][All Lists]
[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
- Shared library depending on a convenience library,
Bjarne Vestergaard <=