This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
--with-sysroot newbie troubles: "ld: cannot open crt1.o"
- From: Daniel Kegel <dkegel at google dot com>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 08 Jan 2004 14:09:31 -0800
- Subject: --with-sysroot newbie troubles: "ld: cannot open crt1.o"
I built an x86 -> x86_64 cross toolchain with binutils-2.14.90.0.7,
gcc-3.3-20040105, and glibc-2.3.2 after some futzing, mainly using --with-sysroot
and applying the following speculative patch to work around problems compiling libgcc and friends:
============
--- gcc-3.3-20040105/configure.in.old 2004-01-08 10:53:26.000000000 -0800
+++ gcc-3.3-20040105/configure.in 2004-01-08 11:18:34.000000000 -0800
@@ -1474,7 +1474,7 @@
# being built; programs in there won't even run.
if test "${build}" = "${host}" && test -d ${srcdir}/gcc; then
# Search for pre-installed headers if nothing else fits.
- FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include'
+ FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -B$(build_tooldir)/lib64/ -B$(build_tooldir)/usr/lib/ -B$(build_tooldir)/usr/lib64/ -isystem $(build_tooldir)/include -isystem $(build_tooldir)/usr/include'
fi
if test "x${use_gnu_ld}" = x &&
============
That patch must be reasonably ok, as the resulting bootstrap compiler happily
builds glibc and the final compiler.
BUT: the resulting toolchain can't compile executables; gcc hello.c fails with
ld: cannot open crt1.o: No such file or directory
Binutils was configured with
../binutils-2.14.90.0.7/configure --disable-nls \
--target=x86_64-unknown-linux-gnu \
--prefix=/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3-20040105-glibc-2.3.2 \
--with-sysroot=/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3-20040105-glibc-2.3.2/x86_64-unknown-linux-gnu
gcc was configured with
../gcc-3.3-20040105/configure \
--target=x86_64-unknown-linux-gnu --host=i686-host_pc-linux-gnu \
--prefix=/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3-20040105-glibc-2.3.2 \
--disable-multilib \
--with-sysroot=/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3-20040105-glibc-2.3.2/x86_64-unknown-linux-gnu \
--disable-nls --enable-threads=posix --enable-symvers=gnu \
--enable-__cxa_atexit --enable-languages=c,c++ --enable-shared \
--enable-c99 --enable-long-long
Running gcc with --verbose shows that crt1.o, crti.o, and crtn.o are passed to
collect2 with no path in front of them (unlike a similar toolchain compiled
without --with-sysroot).
It's as if gcc was expecting the --with-sysroot'd ld to search -L / SEARCH_DIR
directories for crt1.o and friends, but as far as I know, it only searches
those directories for libraries.
I verified that running collect2 with the proper paths inserted in front of
those three files yielded an executable, so this might be the last buglet
between me and a crosstool build script that works for x86_64.
Running collect2 with --verbose shows the SEARCH_DIRs one would expect for
a 32->64 sysrooted crosslinker:
SEARCH_DIR("=/usr/local/lib64"); SEARCH_DIR("=/lib64"); SEARCH_DIR("=/usr/lib64"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");
I verified using strace that gcc / ld makes no attempt to search for crt1.o;
it simply tries to open it in the current directory.
crt1.o is present where you'd expect it:
/opt/crosstool/x86_64-unknown-linux-gnu/gcc-3.3-20040105-glibc-2.3.2/x86_64-unknown-linux-gnu/usr/lib64/crt1.o
So... did I misuse --with-sysroot, or is something else wrong?
Thanks,
Dan