Re: use of libtool for linking executables - rpath problem

[Rob Browning]

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.

The only clean solution I could see to this would be for gcc to
support a --push-state --pop-state (or similar) set of args so that a
given config script could output:

  --push-state -L/usr/lib -lgnome-print -L... -l... --pop-state

and not have it's -L args screw up later flags on the compile line.

But though I've had some agreement from relevant developers, I
wouldn't expect to see this any time soon.

-- 
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