From unknown Sun Jun 22 00:25:45 2025 X-Loop: help-debbugs@gnu.org Subject: bug#15196: Use of rpath in libtool makes LD_LIBRARY_PATH useless Resent-From: Jan Engelhardt Original-Sender: "Debbugs-submit" Resent-CC: bug-libtool@gnu.org Resent-Date: Tue, 27 Aug 2013 08:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 15196 X-GNU-PR-Package: libtool X-GNU-PR-Keywords: To: 15196@debbugs.gnu.org X-Debbugs-Original-To: bug-libtool@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.137759346419918 (code B ref -1); Tue, 27 Aug 2013 08:52:02 +0000 Received: (at submit) by debbugs.gnu.org; 27 Aug 2013 08:51:04 +0000 Received: from localhost ([127.0.0.1]:58290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VEEzP-0005BC-Cw for submit@debbugs.gnu.org; Tue, 27 Aug 2013 04:51:03 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44798) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VEEzJ-0005Ah-HK for submit@debbugs.gnu.org; Tue, 27 Aug 2013 04:50:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VEEzD-0004Or-HT for submit@debbugs.gnu.org; Tue, 27 Aug 2013 04:50:57 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:39272) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEEzD-0004On-EV for submit@debbugs.gnu.org; Tue, 27 Aug 2013 04:50:51 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEEz8-0002WW-8p for bug-libtool@gnu.org; Tue, 27 Aug 2013 04:50:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VEEz2-0004HE-2r for bug-libtool@gnu.org; Tue, 27 Aug 2013 04:50:46 -0400 Received: from ares07.inai.de ([5.9.24.206]:33522) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEEz1-0004FO-MI for bug-libtool@gnu.org; Tue, 27 Aug 2013 04:50:39 -0400 Received: by ares07.inai.de (Postfix, from userid 25121) id 509885208EC; Tue, 27 Aug 2013 10:50:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ares07.inai.de (Postfix) with ESMTP id 30C3D20772297 for ; Tue, 27 Aug 2013 10:50:36 +0200 (CEST) Date: Tue, 27 Aug 2013 10:50:36 +0200 (CEST) From: Jan Engelhardt Message-ID: User-Agent: Alpine 2.10.9 (LSU 9 2013-05-29) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -2.4 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) 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?