This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

question about sysroot and Windows->Linux cross ld


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]