question about sysroot and Windows->Linux cross ld

[Carlos O'Donell]

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.