GNU bug report logs - #15196
Use of rpath in libtool makes LD_LIBRARY_PATH useless

Previous Next

Package: libtool;

Reported by: Jan Engelhardt <jengelh <at> inai.de>

Date: Tue, 27 Aug 2013 08:52:02 UTC

Severity: normal

To reply to this bug, email your comments to 15196 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Jan Engelhardt <jengelh <at> inai.de>
To: bug-libtool <at> gnu.org
Subject: Use of rpath in libtool makes LD_LIBRARY_PATH useless
Date: Tue, 27 Aug 2013 10:50:36 +0200 (CEST)
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.