Hello,
wf...@niif.hu wrote:
Roumen Petrov <bugtr...@roumenpetrov.info> writes:
wf...@niif.hu wrote:
I'm experimenting with the attached skeleton project on a Debian buster
Debian is key word.
system (autoconf 2.69-11, automake 1:1.16.1-4 and libtool 2.4.6-9):
Libtool is patched, not FSF.
[SNIP]
/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
[SNIP]
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?
Not reproducible with FSF release.
Could you please share your link command? Does you system use the new
dynamic tags (DT_RUNPATH instead of DT_RPATH)?
This does not make sense. With and without new dtags result will be the
same.
It is long history It starts with 1* (1.5) libtool . Libtool 1.5 has
some issues with multiple dependent libraries (more then two).
From debian was proposed a patch related to library dependencies.
Unfortunately patch break existing regression test. From debian never
was proposed version that pass regression test.
Libtool 2.0 fixes his issues related to multiple libraries. On the same
Debian did not stop to contribute patch that breaks libtool.
As result when I decide to build something from source always to updated
sources to FSF version.
So the right question is did reporter test with FSF version?
Regards,
Roumen Petrov
