bug#24296: lt wrapper script puts the .libs rpath last instead of first

[Ray Satiro]

I am building a shared library and a program that uses it and I need to 
run it uninstalled. libtool creates a lt- version of the program with an 
rpath to the uninstalled shared library, but the problem is I also set 
rpaths and libtool puts its rpath after mine instead of before.

I build curl in Ubuntu similar to this:

LDFLAGS="-Wl,-rpath,/usr/local/ssl/lib -Wl,-rpath,/usr/local/lib" 
./configure [OPTIONS REMOVED FOR BREVITY]
make

I end up with

lib/.libs/libcurl.so
src/curl    <--- libtool wrapper script
src/.libs/lt-curl

When I run src/curl it execs lt-curl which has an rpath for 
/usr/local/lib before lib/.libs, and so it loads the libcurl.so from 
/usr/local/lib. Reviewing the wrapper script I can see libtool appends 
its rpath instead of putting it first. relink-command looks basically 
like this:

gcc -O2 -Wno-system-headers -Wl,-rpath -Wl,/usr/local/ssl/lib -Wl,-rpath 
-Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib -o \$progdir/\$file 
[OBJECTS REMOVED FOR BREVITY] -L/usr/local/ssl/lib -L/usr/local/lib 
../lib/.libs/libcurl.so -lssl -lcrypto -lz -Wl,-rpath 
-Wl,/home/owner/curl-7.50.1/lib/.libs

I initially reported this to the cURL project, which I am a part of. The 
bug is https://github.com/curl/curl/issues/432 but I couldn't figure it out.

I attempted to work around this problem when I know src/curl is used by 
using LD_PRELOAD, like

LD_PRELOAD=$PWD/lib/.libs/libcurl.so make test

Recently though I realized a bunch of our tests are overriding 
LD_PRELOAD, and I don't have a work around for those cases at the moment.

I believe appending the lib/.libs rpath instead of prepending it could 
be a bug in libtool.

libtool (GNU libtool) 2.4.6 Debian-2.4.6-0.1
Ubuntu 16 LTS
4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 x86_64 
x86_64 x86_64 GNU/Linux