This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/22747] ld.so --library-path doesn't always work
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 25 Jan 2018 20:32:55 +0000
- Subject: [Bug dynamic-link/22747] ld.so --library-path doesn't always work
- Auto-submitted: auto-generated
- References: <bug-22747-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=22747
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |carlos at redhat dot com
--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
If you use --enable-hardcoded-path-in-tests the tests are built with -Wl,-rpath
and this embeds the library search path into DT_RPATH/DT_RUNPATH, both of which
take precedence over ld.so's --library-path which is equivalent to setting
LD_LIBRARY_PATH IIRC.
To prove this you could try using LD_PRELOAD to preload the required libraries
and that would certainly force them to be loaded before DT_RPATH/DT_RUNPATH.
Therefore I don't think there is a bug here.
(a) ld.so --library-path is equivalent to LD_LIBRARY_PATH.
(b) If you use DT_RPATH/DT_RUNPATH in a binary, like is done with
--enable-hardcoded-path-in-tests, you must use LD_PRELOAD to get a different
set of loaded libraries that match the ld.so you're using to run the test.
Does that make sense?
--
You are receiving this mail because:
You are on the CC list for the bug.