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: Carlos O'Donell <carlos at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>, binutils at sourceware dot org, "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Douglas Rupp <rupp at adacore dot com>, Erwan Le Guillou <leguillou at adacore dot com>
- Date: Wed, 17 Jan 2018 13:42:11 -0800
- Subject: Re: question about sysroot and Windows->Linux cross ld
- Authentication-results: sourceware.org; auth=none
- References: <20180117175405.6elswkryoba5yq3d@adacore.com>
On 01/17/2018 09:54 AM, Joel Brobecker wrote:
> We created a sysroot on the host by copying the various headers
> and libraries from our target. We then passed that sysroot to
> the compiler using --sysroot=/path/to/sysroot.
>
> A cross-compiler hosted on GNU/Linux is able to link a program fine,
> but the same cross-compiler hosted on Windows fails to link with
> the following error:
>
> | c:/[...]/gcc/install/bin/../libexec/gcc/powerpc-generic-linux-gnu/6.4.1/ld.exe: cannot find //lib/libc.so.6
> | c:/[...]/gcc/install/bin/../libexec/gcc/powerpc-generic-linux-gnu/6.4.1/ld.exe: cannot find //lib/libc_nonshared.a
> | c:/[...]/gcc/install/bin/../libexec/gcc/powerpc-generic-linux-gnu/6.4.1/ld.exe: cannot find //lib/ld.so.1
> | collect2.exe: error: ld returned 1 exit status
>
> Investigating a bit, we found that some of the shared libraries
> are ld scripts. In particular, one of them contains:
>
> | /* GNU ld script
> | Use the shared library, but some functions are only in
> | the static library, so try that secondarily. */
> | OUTPUT_FORMAT(elf32-powerpc)
> | GROUP ( //lib/libc.so.6 //lib/libc_nonshared.a AS_NEEDED ( //lib/ld.so.1 ) )
>
> After reading the documentation a bit and tweaking around, we found
> that if we replaced the paths above to start with "=/" instead of "//"
> (eg: "//lib/" -> "=/lib"), the linker is able to find the shared
> library inside our sysroot. In other words, unless we prefix the paths
> in the ld script with '=', it seems like ld is not applying the sysroot
> as one might expect.
>
> Given that the same command with the same sysroot but hosted on
> a GNU/Linux machine works, we're thinking this might be a bug,
> either in the linker itself, or perhaps in the way we build
> the linker.
>
> Any opinion on this? We'll investigate the problem, but it would
> help us if we knew that we're trying to achieve the correct result :).
I'm TO'ing Joseph Myers since he often had a strong opinion about how
this should work (and was the author of --enable-poison-system-directories).
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.
If you fix this, please also update the binutils manual to more clearly
spell out exactly where and when $SYSROOT is used, and the answer I expect
is "everywhere." :-)
--
Cheers,
Carlos.