[EMAIL PROTECTED] (Paul Jarc) writes: > Uh? AIUI, the basename of the shared library is embedded in the > executable, but not the full path. The library is searched for first > in the -rpath directories (also embedded in the executable) and then > in the global directories such as /usr/lib.
The problem I'm talking about is if Makefile.am's use LDFLAGS = `gnome-config --libs foo` `foo-config --libs bar` then if you've got a normal gnome-dev package installed, such that it's libs are in /usr/lib, it will (or at least it used to) put -L/usr/lib into LDFLAGS ahead of whatever foo-config specifies. Now if the system you're on has foo version 1.1 installed in /usr but you want to develop for foo version 2.0, even if you install foo 2.0 into ~/opt/foo-2.0, you can't develop with it because gnome-config's -L/usr/lib will force you to use the foo 1.1 version in /usr/lib. Now you can get around this by changing the order above, but that won't scale, and breaks if the situation wrt foo and gnome were reversed. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
