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.

Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

Reply via email to