This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

--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


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