On Thu, 16 Nov 2017 14:49:01 -0500 Nick Bowler <nbow...@draconx.ca> wrote:
> If that is not happening then maybe the libraries and/or programs are > being linked incorrectly, or perhaps there's a bug in libtool. > > Example: > > build+install libfoo to non-system location: > % libtool --tag=CC --mode=compile gcc -c foo.c > % libtool --tag=CC --mode=link gcc -rpath /tmp/instlib -o libfoo.la > foo.lo % libtool --mode=install cp libfoo.la /tmp/instlib > > build libbar, linked against libfoo: > % libtool --tag=CC --mode=compile gcc -c bar.c > % libtool --tag=CC --mode=link gcc -rpath /usr/local/lib -o > libbar.la \ bar.lo /tmp/instlib/libfoo.la > > build application linked against uninstalled libbar: > % libtool --tag=CC --mode=compile gcc -c app.c > % libtool --tag=CC --mode=link gcc -o app app.lo libbar.la > > Inspection of results: > % ldd .libs/app > [...] > libbar.so.0 => not found > libfoo.so.0 => /tmp/instlib/libfoo.so.0 (0x00007fec8f7a9000) > > [we see that that the executable has the nonstandard location for > libfoo, and libbar is not installed so it is not found by ldd, and > finally...] > > % libtool --mode=execute ./app > [works correctly] Ah interesting. I see a number of `-rpath` arguments in theabove, which I don't have in my case. I wonder if that explains it. Should the .pc file from the first library be emitting that as part of the --libs output then? -- Paul "LeoNerd" Evans leon...@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
