bug#15196: Use of rpath in libtool makes LD_LIBRARY_PATH useless

[Jan Engelhardt]

My Linux-based openSUSE 12.3 system has a /usr/lib64/libxml2.la. It
contains:

dlname='libxml2.so.2'
library_names='libxml2.so.2.9.0 libxml2.so.2 libxml2.so'
old_library=''
inherited_linker_flags=''
dependency_libs=' -ldl -lz -llzma -lm'
weak_library_names=''
current=11
age=9
revision=0
installed=yes
shouldnotlink=no
dlopen=''
dlpreopen=''
libdir='/usr/lib64'

I have a testcase libx1 with Makefile.am:

lib_LTLIBRARIES = libx1.la
libx1_la_SOURCES =
libx1_la_LIBADD = -lxml2

Producing libx1.la using libtool-2.4.2 produces a gcc link command like:

/bin/sh ./libtool  --tag=CC   --mode=link gcc  -g -O2   -o libx1.la
        -rpath /usr/local/lib  -lxml2 
libtool: link: gcc -shared  -fPIC -DPIC   -Wl,-rpath -Wl,/usr/lib64
        -Wl,-rpath -Wl,/usr/lib64 /usr/lib64/libxml2.so -ldl -lz
        -llzma -lm -O2 -Wl,-soname -Wl,libx1.so.0
        -o .libs/libx1.so.0.0.0

By having RPATH entries in the libx1.so file, the functionality of
the LD_LIBRARY_PATH environment variable is rendered useless, making
it impossible to selectively override libraries from (in this case)
/usr/lib64.

Observed:

$ LD_LIBRARY_PATH=$HOME/libxml2/.libs ldd .libs/libx1.so
        libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007ff3b168e000)

Expected:

$ LD_LIBRARY_PATH=$HOME/libxml2/.libs ldd .libs/libx1.so
        libxml2.so.2 => /home/jengelh/libxml2/.libs/libxml2.so.2 (blah)

According to the ld.so manual, DT_RUNPATH would be the ELF tag
which has lower precedence than LD_LIBRARY_PATH and which I think
should be used instead to hold the required .libs paths.
I do however not find any option in ld(1) to emit RUNPATH
instead of RPATH.
Are we totally screwed?