Relative paths in *_LDADD vs absolute paths in .la dependencies
With a fairly recent CVS HEAD libtool (but I see the same with 1.5.8) the following command: /bin/sh ../libtool --tag=CXX --mode=link g++ -o quartzcheck \ quartzcheck-quartzcheck.o ../testsuite/libbtreecheck.la ../libxapian.la causes libtool to execute (my wrapping): g++ -o .libs/quartzcheck quartzcheck-quartzcheck.o \ ../testsuite/.libs/libbtreecheck.a \ /s2/olly/svn/xapian/xapian-core/.libs/libxapian.so ../.libs/libxapian.so \ -Wl,--rpath -Wl,/u1/olly/install/lib The full path to libxapian.so comes from libbtreecheck.la's dependencies, while the relative path (which leads to the same files) comes from the link line. I think this is mostly a cosmetic problem, except that it probably causes the linker more work unless it realises the two libxapian.so's are actually the same. Is there a way to avoid this happening - e.g. are paths to .la files specified in LDADD meant to be absolute rather than relative? I'd rather not remove the explicit mention of libxapian.la from quartzcheck_LDADD since it's really an implementation detail of libbtreecheck.la that it depends on libxapian.la. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Shared library depending on a convenience library
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 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Shared library depending on a convenience library
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
