Steve Tell <[EMAIL PROTECTED]> writes: > In additional experimention, I found that simply removing -L/usr/lib > altogether works in this case, perhaps because of the --rpath. > "Correct" for me here is building a libguilereadline.so that depends > explicitly on the versioned name libguile.so.14 (which I guess will > be searched for at runtime)
We've had a similar ongoing problem with the foo-config type scripts, i.e. "foo-config --libs". If any one of them that you're using to compile a given project produces -I/usr/include or -L/usr/lib, and if its flags appear on your compile/link line ahead of some other lib, then its impossible to build your project using a non /usr/lib install of some library that's also installed in /usr/lib. For example, if you have guile 1.4 installed in /usr/lib, and you install the guile 1.5 beta into /opt/guile-1.5, you will be unable to compile or link a gtk app against guile 1.5 if any of the gtk config scripts output -L/usr/lib and those flags appear before -lguile on the link line. On Linux and similar systems, could libtool, foo-config scripts, etc. just special case (and omit) -L/usr/lib -L/lib and -I/usr/include? Thanks -- 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
