Re: transitive shared library dependencies and installation
Bob Friesenhahn writes: > On Wed, 1 Jan 2020, wf...@niif.hu wrote: > >> make[1]: Leaving directory '/home/wferi/ha/pacemaker/translib' >> make: *** [Makefile:798: install-am] Error 2 >> >> No cyclic dependencies here, so this can be worked around by >> >> -lib_LTLIBRARIES = a/liba.la b/libb.la >> +lib_LTLIBRARIES = b/libb.la a/liba.la >> >> in this case; is this expected (and documented) behavior? > > In this case libtool is a slave of Automake and Automake is > controlling the build and installation order. This means that it > should be expected behavior. Installation is serialized and thus > order matters. But in case of a dependency cycle there's no correct order if libtool insists on using the installation directory for the -L option for relinking. And the installation directory may contain an incompatible version of the library anyway, just like it happens below. >> and use it from liba, linking the final binary fails: >> >> $ make >> [...] >> /bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 -avoid-version -o >> translib translib.o a/liba.la >> libtool: link: gcc -g -O2 -o .libs/translib translib.o a/.libs/liba.so >> -Wl,-rpath -Wl,/tmp/translib/lib >> /usr/bin/ld: a/.libs/liba.so: undefined reference to `b2' >> >> As I understand it, the -rpath linker option on the above command makes >> a/.libs/liba.so use the already installed (old) version of libb, which >> lacks the b2 symbol. What's the solution here? Why isn't that -rpath >> option "delayed" until the relinking phase? > > The -rpath linker option did not cause the library to be used. The above gcc linking command is successful if I omit the -rpath option. (The built-in RUNPATH of liba.so contains the build directory first. Just for the record: Debian's ld defaults to --enable-new-dtags.) > The '-r' in -rpath stands for 'run' and thus it is a path stored in a > built shared library or executable which tells it where to search for > other libraries when th program is executed. True, but man ld states in the -rpath-link option description that the directories specified by -rpath options are used with a very high priority for locating required shared libraries. > Perhaps the controlling parameter is hardcode_into_libs. If your > libtool comes from an OS distribution rather than from a FSF/GNU > tarball, then it is possible that its behavior may have been modified. I don't know what to expect, here's what I can see: $ ./libtool --config | fgrep hardcode_into_libs hardcode_into_libs=yes > I am not seeing 'libb' mentioned on the link line and that may be the > cause of the problem you are seeing. Sure enough, adding libb.la explicitly to the link command works around the issue, but since the binary does not use libb directly, it doesn't sound like a good solution to me, because it leads to overlinking. -- Thanks, Feri
Re: transitive shared library dependencies and installation
On Wed, 1 Jan 2020, wf...@niif.hu wrote: make[1]: Leaving directory '/home/wferi/ha/pacemaker/translib' make: *** [Makefile:798: install-am] Error 2 No cyclic dependencies here, so this can be worked around by -lib_LTLIBRARIES = a/liba.la b/libb.la +lib_LTLIBRARIES = b/libb.la a/liba.la in this case; is this expected (and documented) behavior? In this case libtool is a slave of Automake and Automake is controlling the build and installation order. This means that it should be expected behavior. Installation is serialized and thus order matters. and use it from liba, linking the final binary fails: $ make [...] /bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 -avoid-version -o translib translib.o a/liba.la libtool: link: gcc -g -O2 -o .libs/translib translib.o a/.libs/liba.so -Wl,-rpath -Wl,/tmp/translib/lib /usr/bin/ld: a/.libs/liba.so: undefined reference to `b2' As I understand it, the -rpath linker option on the above command makes a/.libs/liba.so use the already installed (old) version of libb, which lacks the b2 symbol. What's the solution here? Why isn't that -rpath option "delayed" until the relinking phase? The -rpath linker option did not cause the library to be used. The '-r' in -rpath stands for 'run' and thus it is a path stored in a built shared library or executable which tells it where to search for other libraries when th program is executed. The libtool configuration may be dumped using ./libtool --config Perhaps the controlling parameter is hardcode_into_libs. If your libtool comes from an OS distribution rather than from a FSF/GNU tarball, then it is possible that its behavior may have been modified. I am not seeing 'libb' mentioned on the link line and that may be the cause of the problem you are seeing. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
transitive shared library dependencies and installation
Hi,
I'm experimenting with the attached skeleton project on a Debian buster
system (autoconf 2.69-11, automake 1:1.16.1-4 and libtool 2.4.6-9):
$ autoreconf -f -i
$ ./configure --prefix=/tmp/translib
$ make
$ ./translib; echo $?
6
$ make install
make[1]: Entering directory '/home/wferi/ha/pacemaker/translib'
/bin/mkdir -p '/tmp/translib/lib'
/bin/bash ./libtool --mode=install /usr/bin/install -c a/liba.la b/libb.la
'/tmp/translib/lib'
libtool: warning: relinking 'a/liba.la'
libtool: install: (cd /home/wferi/ha/pacemaker/translib; /bin/bash
"/home/wferi/ha/pacemaker/translib/libtool" --tag CC --mode=relink gcc -g -O2
-avoid-version -o a/liba.la -rpath /tmp/translib/lib a/a.lo b/libb.la )
libtool: relink: gcc -shared -fPIC -DPIC a/.libs/a.o -Wl,-rpath
-Wl,/tmp/translib/lib -L/tmp/translib/lib -lb -g -O2 -Wl,-soname -Wl,liba.so
-o a/.libs/liba.so
/usr/bin/ld: cannot find -lb
collect2: error: ld returned 1 exit status
libtool: error: error: relink 'a/liba.la' with the above command before
installing it
make[1]: *** [Makefile:446: install-libLTLIBRARIES] Error 1
make[1]: Leaving directory '/home/wferi/ha/pacemaker/translib'
make: *** [Makefile:798: install-am] Error 2
No cyclic dependencies here, so this can be worked around by
-lib_LTLIBRARIES = a/liba.la b/libb.la
+lib_LTLIBRARIES = b/libb.la a/liba.la
in this case; is this expected (and documented) behavior?
Anyway: if, after a successful installation, I introduce a new symbol
(b2) in libb
diff --git a/a/a.c b/a/a.c
index ffc6553..8edd6f5 100644
--- a/a/a.c
+++ b/a/a.c
@@ -3,5 +3,5 @@
int a (int x)
{
-return b(x)+1;
+return b(x)+b2(x)+1;
}
diff --git a/b/b.c b/b/b.c
index 27bd35f..a723efc 100644
--- a/b/b.c
+++ b/b/b.c
@@ -4,3 +4,8 @@ int b (int x)
{
return x+2;
}
+
+int b2 (int x)
+{
+return x+3;
+}
diff --git a/b/b.h b/b/b.h
index 2290498..c0ea0fb 100644
--- a/b/b.h
+++ b/b/b.h
@@ -1 +1,2 @@
int b (int x);
+int b2 (int x);
and use it from liba, linking the final binary fails:
$ make
[...]
/bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 -avoid-version -o
translib translib.o a/liba.la
libtool: link: gcc -g -O2 -o .libs/translib translib.o a/.libs/liba.so
-Wl,-rpath -Wl,/tmp/translib/lib
/usr/bin/ld: a/.libs/liba.so: undefined reference to `b2'
As I understand it, the -rpath linker option on the above command makes
a/.libs/liba.so use the already installed (old) version of libb, which
lacks the b2 symbol. What's the solution here? Why isn't that -rpath
option "delayed" until the relinking phase?
--
Thanks,
Feri
translib.tgz
Description: application/gtar-compressed
