Re: [PATCH v2 04/12] ltmain.in: Don't encode RATHS which match default linker paths

On Sat, 16 Apr 2022, Sam James wrote:

> From: Richard Purdie <[email protected]>
>
> We don't want to add RPATHS which match default linker search paths, they're
> a waste of space. This patch filters libtools list of paths to encoode and
> removes the ones we don't need.

While cross-compiling some software ("Curl") for a target which 
already had an older install present, libtool ended up defeating me. 
I wanted to produce my own libcurl and have the apps specifically 
linking with it, use the libcurl that I had built.  I wanted to leave 
the libcurl that came with the system in place for the many other 
existing apps which needed it.  Unfortunately, the add-on software was 
already configured to install and use libraries in "/usr/lib" and the 
popular/default "/usr/local/lib" was included in the default linker 
path so that would not have worked either.

The libtool I was using (originating from Ubuntu Linux) stripped the 
rpath (which was provided like '-Wl,rpath=/usr/lib') so I was unable 
to embed an rpath in the libcurl I built so that applications linked 
with that libcurl would find it.

The end result was that apps linked with the new libcurl tried to use 
an older libcurl on the system, and failed to run.

I was unable to circumvent this issue caused by libtool.

It is useful if user-provided options have priority over built-in 
optimizations in libtool.

As a user, I strongly suggest that libtool honor user-supplied options 
to the configure script and provided to the libtool command line, even 
while it optimizes other unneeded options away.

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt