GNU bug report logs -
#15196
Use of rpath in libtool makes LD_LIBRARY_PATH useless
Previous Next
To reply to this bug, email your comments to 15196 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-libtool <at> gnu.org
:
bug#15196
; Package
libtool
.
(Tue, 27 Aug 2013 08:52:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jan Engelhardt <jengelh <at> inai.de>
:
New bug report received and forwarded. Copy sent to
bug-libtool <at> gnu.org
.
(Tue, 27 Aug 2013 08:52:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 301 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.