This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 2/2 v5] gold: enable new dtags by default
- From: Cary Coutant <ccoutant at google dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Mike Frysinger <vapier at gentoo dot org>, "H.J. Lu" <hjl dot tools at gmail dot com>, Ian Lance Taylor <iant at google dot com>, Binutils <binutils at sourceware dot org>
- Date: Wed, 5 Feb 2014 08:53:01 -0800
- Subject: Re: [PATCH 2/2 v5] gold: enable new dtags by default
- Authentication-results: sourceware.org; auth=none
- References: <1356420600-11507-1-git-send-email-vapier at gentoo dot org> <201302200115 dot 32464 dot vapier at gentoo dot org> <CAMe9rOowjdKTo3L+3W=X6XeQWDKanCaae+Z_sXpRnOj5R5KggA at mail dot gmail dot com> <201302201340 dot 48380 dot vapier at gentoo dot org> <CAHACq4oNM-JyjMXtJJmjfLq3PJG2a7C+t9O=8M=ifOvp+h6L=w at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1402050221150 dot 25166 at digraph dot polyomino dot org dot uk>
>> It seems to me that the cases where DT_RUNPATH causes breakage are
>> broken as intended, and the second-level libraries that depend on
>> third-level libraries should have an embedded DT_RUNPATH that says
>> where to find them. Of course, since they've been working for so long,
>
> Say you have a sysroot containing what's eventually intended to be some
> system's root filesystem. None of the libraries therein should have RPATH
> or RUNPATH set - paths on the host or the system used for testing wouldn't
> work on the final target system, and on the final system the libraries
> will be in standard directories such as /usr/lib. To build a test binary
> that uses the sysroot before it's installed in a root filesystem, you use
> -Wl,-dynamic-linker,/sysroot/<ld.so path>
> -Wl,-rpath,/sysroot/lib:/sysroot/usr/lib. For this (which is the main
> purpose I use -rpath for at all, building programs to use non-installed
> libraries) to work reliably relies on all dependencies being found via
> that RPATH, both direct and indirect. I consider this part of the
> semantics of the -rpath option; that is, generating DT_RUNPATH should be a
> different option such as -runpath.
Why is LD_LIBRARY_PATH not the right way to do this? For the same
reason that you don't want to build the libraries in the sysroot
specially, I'd think that you'd want to build test binaries exactly
the way they'd be built on the test system, rather than build them
with a special linker option.
For this scenario, maybe what we really need is an LD_SYSROOT
environment variable. When the dynamic linker starts up, if it's not
under the sysroot, it could re-exec the sysrooted dynamic linker, and
all library searches would be subject to sysroot substitution.
-cary