Re: use of libtool for linking executables - rpath problem

[Paul Jarc]

Rob Browning <address@hidden> wrote:
> Bruno Haible <address@hidden> 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