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
