This is the mail archive of the
mailing list for the binutils project.
Re: [RESEND][PATCH] ld: -rpath must search under sysroot
- From: Andy Ross <andy dot ross at windriver dot com>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: binutils at sourceware dot org, Alan Modra <amodra at gmail dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Mon, 22 Oct 2012 09:01:11 -0700
- Subject: Re: [RESEND][PATCH] ld: -rpath must search under sysroot
- References: <firstname.lastname@example.org> <5050D280.email@example.com> <20121022052959.GO3263@bubble.grove.modra.org> <firstname.lastname@example.org>
On 10/21/2012 11:14 PM, Mike Frysinger wrote:
On Monday 22 October 2012 01:29:59 Alan Modra wrote:
I agree that your patch makes sense, but I hesitate to apply the
change for two reasons:
a) It's odd to have -rpath add the sysroot but -rpath-link not do so.
agreed. we should update -rpath-link to search the sysroot too.
Actually, this verifiably breaks builds in the wild. The first
version I posted did exactly that, but I quickly found spots where
projects are passing a relative path to -rpath-link (e.g. ../lib)
which will pick up even more host-polluting libraries. Basically
people seem to have figured out that -rpath-link doesn't honor sysroot
and have already worked around it. Changing this seems like it would
be a needless (if perhaps less surprising) incompatibility.
b) I wonder how many people already add the sysroot to their -rpath
argument, and would have their builds broken by this change.
i think we already have that problem since gold is behaving the correct way.
i'm also not sure who would actually be relying on this behavior. i'd hazard
a guess that the vast majority of people using a sysroot are cross-compiling
which means the host paths contain incompatible formats.
The case I hit was Yocto/Openembedded, where everything is built with
a cross toolchain but for an architecture which often matches the
host. Another post in this thread pointed out that ChromiumOS hit the
bug for similar reasons.
Really, the current behavior can't possibly work reliably in the face
of these toolchains. Consider the case of a project that drops
RPATH-located libraries in "/my/plugin/dir". Now install it on the
host, and try to link a different version using a cross toolchian.
You can't, because you can't set the RPATH without hitting the wrong