Re: transitive shared library dependencies and installation

[Roumen Petrov]

address@hidden wrote:
> 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):
[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

Libtool does not change "order" :(. Automake just uses project rules.


Let view Makefile.in
...
install-exec-am: install-binPROGRAMS install-libLTLIBRARIES
...
install-binPROGRAMS: install-libLTLIBRARIES
...
install-libLTLIBRARIES: $(lib_LTLIBRARIES)
...
Above dependency explain all - lib_LTLIBRARIES is project (sample) 
specific. Project should ensure order.



[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.

Regards,
Roumen Petrov