question about sysroot and Windows->Linux cross ld

question about sysroot and Windows->Linux cross ld

[Joel Brobecker]

Hello,

We are working on a a Windows-to-Linux compiler, and we noticed
something with respect to shared library linking which looks like
it might be a bug, and we'd like to have your opinion before we go
too deep into trying to solve this.

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 :).

Thank you!
-- 
Joel

Re: question about sysroot and Windows->Linux cross ld

[Hans-Peter Nilsson]

On Wed, 17 Jan 2018, Joel Brobecker wrote:
> Hello,
>
> We are working on a a Windows-to-Linux compiler, and we noticed
> something with respect to shared library linking which looks like
> it might be a bug, and we'd like to have your opinion before we go
> too deep into trying to solve this.
>
> 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

>    | GROUP ( //lib/libc.so.6 //lib/libc_nonshared.a  AS_NEEDED ( //lib/ld.so.1 ) )

> 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 suggest having a look at the "#if defined (_WIN32) &&
!defined (__CYGWIN32__) *slash = ..." thing in ldfile.c.

Obviously, maybe also find out where the "//" comes from.  I'm
guessing that's supposed to be "/" (maybe somewhere, a
"sysroot=/" vs. "sysroot=" foulup) and may be handled
differently in "Windows" compared to "Linux" when found at the
start or inside (prepended by the sysroot) a path.

brgds, H-P

Re: 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.

Re: question about sysroot and Windows->Linux cross ld

[Joseph Myers]

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

Re: question about sysroot and Windows->Linux cross ld

[Joel Brobecker]

Just a quick message to say Thank You All. This gives us confidence
that we're trying to do something that makes sense. We'll let you know
when we have more info on this!

-- 
Joel

[PATCH] sysroot and Windows->Linux cross ld

[Douglas B Rupp]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]


In regards to a discussion about a bug on or about Jan 17 on the above 
subject, please find attached my patch.

I don't have write access to binutils at this time.

The problem was the ld expect libiberty/lrealpath() to always return a 
path, but in some cases it returns a prefix. It seemed like too much of 
an earthquake to propose a fix to lrealpath.

--Douglas Rupp
AdaCore


[-- Attachment #2: p.log --]
[-- Type: text/x-log, Size: 121 bytes --]

ld/
	* ldmain.c (main): Remove any trailing directory separator
	from ld_canon_sysroot and adjust ld_canon_sysroot_len.


[-- Attachment #3: p.diff --]
[-- Type: text/x-patch, Size: 804 bytes --]

diff --git ld/ldmain.c ld/ldmain.c
index e049de3..524b7cd 100644
--- ld/ldmain.c
+++ ld/ldmain.c
@@ -237,9 +237,17 @@ main (int argc, char **argv)
   if (*ld_sysroot)
     ld_canon_sysroot = lrealpath (ld_sysroot);
   if (ld_canon_sysroot)
-    ld_canon_sysroot_len = strlen (ld_canon_sysroot);
+    {
+      ld_canon_sysroot_len = strlen (ld_canon_sysroot);
+
+      /* is_sysrooted_pathname() relies on no trailing dirsep.  */
+      if (IS_DIR_SEPARATOR (ld_canon_sysroot [ld_canon_sysroot_len - 1]))
+        ld_canon_sysroot [--ld_canon_sysroot_len] = '\0';
+    }
   else
-    ld_canon_sysroot_len = -1;
+    {
+      ld_canon_sysroot_len = -1;
+    }
 
   /* Set the default BFD target based on the configured target.  Doing
      this permits the linker to be configured for a particular target,

Re: [PATCH] sysroot and Windows->Linux cross ld

[Nick Clifton]

Hi Douglas,

> In regards to a discussion about a bug on or about Jan 17 on the above subject, please find attached my patch.

Patch applied.  Thanks for pursuing this.

Cheers
  Nick