Hello, I'm trying to bootstrap a gcc+glibc in arm, in a Sheevaplug, and I'm encountering a problem I don't know how to fix. I'll study the CLFS for arm better, maybe that gives some clues, but here is what I find.
When building gcc using the toolchain I have in debian or fedora in the Sheevaplug, I find that once xgcc is ready, it cannot link binaries because of this problem in 'intl/configure': configure:2118: checking for C compiler default output file name configure:2121: /tmp/nix-build-0ya2rzk8z4073mcjijkzk6h2l56z0kj7-gcc-4.3.3.drv-0/build/./prev-gcc/xgcc -B/tmp/nix-build-0ya2rzk8z4073mcjijkzk6h2l56z0kj7-gcc-4.3.3.drv-0/build/./prev-gcc/ -B/nix/store/qjlwb839fa2j22rgppgmdd35b2wd1ykp-gcc-4.3.3/armv5tel-unknown-linux-gnueabi/bin/ -g -O2 -g0 -I/nix/store/fmlwk8l44d60cl8a53m1q8bak2ndadp2-gmp-4.3.1/include -I/nix/store/npx27c0azmmsc81d2i0vk4lsc8ji7yvn-mpfr-2.4.1/include -isystem /usr/include -fprofile-generate -Wl,--strip-debug -Wl,-L/usr/lib64 -Wl,-L/usr/lib conftest.c >&5 /usr/bin/ld: crt1.o: No such file: No such file or directory collect2: ld returned 1 exit status The file crt.1.o stays in /usr/lib. I checked the -dumpspecs of the distro gcc and the new xgcc, and they don't look much different regarding crt1.o. I'll try stracing that xgcc, trying to guess where ld wants that crt1.o. Maybe it's a binutils problem? I'm using the system binutils and glibc meanwhile. Regards, Lluís.
