GNU bug report logs -
#15196
Use of rpath in libtool makes LD_LIBRARY_PATH useless
Previous Next
Full log
View this message in rfc822 format
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?
This bug report was last modified 11 years and 324 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.