Rob Browning <[EMAIL PROTECTED]> wrote: > Bruno Haible <[EMAIL PROTECTED]> writes: >> 3) Introduce a libintl-config script that sets outputs the right -L and >> -rpath option. > > This may or may not help you if you're linking with *any* other tools > that are installed in /usr/lib and their foo-config scripts output > -L/usr/lib. > > In that case you *cannot* in general be assured of linking against a > locally installed version of libintl whenever you also have another > version (including the development .so links) installed in /usr/lib. > The one in /usr/lib, if the other package's -L/usr/lib comes first, > will take prececence.
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. As a side note, it'd be nice if specifying the full path to a shared library on the ld command line would cause the full path to be embedded in the executable so no searching would be necessary. The ELF spec seems to allow this. I doubt anyone uses full paths to shared libraries currently, but if we want to worry about that, we could introduce a new flag to turn on this behavior. paul _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool