On Sat, 16 Apr 2022, Sam James wrote:
From: Richard Purdie <richard.pur...@linuxfoundation.org>
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.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt