Roumen Petrov <bugtr...@roumenpetrov.info> writes: > wf...@niif.hu wrote: > >> 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.
Fair enogh, but my point (which I didn't really emphasize) is that installation could work in any order, if relinking didn't depend on already installed libraries. It's even necessary for mutually dependent libraries. >> 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)? -- Thanks, Feri