This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: question about sysroot and Windows->Linux cross ld
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, <binutils at sourceware dot org>, Douglas Rupp <rupp at adacore dot com>, Erwan Le Guillou <leguillou at adacore dot com>
- Date: Wed, 17 Jan 2018 22:37:50 +0000
- Subject: Re: question about sysroot and Windows->Linux cross ld
- Authentication-results: sourceware.org; auth=none
- References: <20180117175405.6elswkryoba5yq3d@adacore.com> <7c54b3d7-5c98-12e7-ac9a-506270ad268f@redhat.com>
On Wed, 17 Jan 2018, Carlos O'Donell wrote:
> My preference is that if you use the --sysroot that all paths must be
> rooted in the sysroot, but may fall back to non-sysroot lookups if the
> sysroot does not contain the files being searched. Note that I was
> used to working with --enable-poison-system-directories (out-of-tree
> patch) to prevent this, but I don't see it submitted anywhere, which
> is unfortunate.
>
> Therefore I think there is a problem here, but it is unique to the linker
> script handling of paths not being sysrooted by default. I think they
> should be.
My understanding is that if the toolchain is configured
--with-sysroot=<something> (both GCC and binutils configured that way),
and if the libc.so linker script is found via a sysrooted path (*not* via
an ordinary -L path), then the paths in it are automatically interpreted
relative to the sysroot - and that this already works on Windows host
without additional patches needed. I've no idea about // paths, however
(normally you configure glibc --prefix=/usr and shouldn't have // paths in
the installed linker scripts), though I'd still expect those to be
interpreted as sysroot-relative rather than as //host/mount/file paths.
It will *not* work if the libc.so linker script is found via a
non-sysrooted path, and may not work if you use --sysroot= with a
toolchain that wasn't configured to use a sysroot by default.
--
Joseph S. Myers
joseph@codesourcery.com