rpath stripping

[Bob Friesenhahn]

There is a libtool patch going around (and submitted to 
libtool-patches) entitled "ltmain.sh: Fix sysroot paths being encoded 
into RPATHs".

I have previous unfortunate experience with libtool doing this (I 
believe that even the FSF version does some of this).  Libtool 
behavior prevented me from doing something I needed to do.  It is 
pretty common for end users (vs OS distribution maintainers) to want 
to build libraries and install them to some place like /usr/local/lib 
in order support modifications which are not in a similar 
system-provided library.  To me this represents part of the freedom 
promoted by the GNU project.

This was my unfortunate experience:

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