This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
question about sysroot and Windows->Linux cross ld
- From: Joel Brobecker <brobecker at adacore dot com>
- To: binutils at sourceware dot org
- Cc: Douglas Rupp <rupp at adacore dot com>, Erwan Le Guillou <leguillou at adacore dot com>
- Date: Wed, 17 Jan 2018 18:54:05 +0100
- Subject: question about sysroot and Windows->Linux cross ld
- Authentication-results: sourceware.org; auth=none
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