[Clfs-support] Bootstrapping gcc and then (if I could) glibc

Joe Ciccone jciccone at gmail.com
Thu Sep 3 15:57:13 PDT 2009

Hector Oron wrote:
> Hello friendly Lluís,
> 2009/8/27 Lluís Batlle <viriketo at gmail.com>:
>> 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.
> First of all, i let you know I am also interested in the proceeding.
> But I believe this is not the right place to post this comments, nor
> linux-arm lists which is mainly kernel stuff, but maybe CLFS mailing
> lists (clfs-support at lists.cross-lfs.org) or gcc-help at gcc.gnu.org or
> crossgcc at sourceware.
> Debian-arm list is likely used for Debian related issues. Would you
> like to follow-up at clfs-support mailing list (CC: there)?
>> 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':
> Can be it disabled? Which are your ./configure commands?
> a) Maybe try something similar to get the bootstrap compiler:
> ./configure --target=arm-linux-gnueabi
> --prefix=/usr/arm-linux-gnueabi/ --disable-nls --without-headers
> --with-newlib --disable-shared --disable-decimal-float
> --disable-threads --disable-libssp --disable-libgomp
> --disable-libmudflap --enable-languages=c
Assuming your host system is not a compatible arm architecture I bet
you'd have problems.
> b) Then compile the C library
> c) Then compile again GCC
>> 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.
> ... please correct me if i am wrong, but should not you be using
> crt1.o for the target system instead your host one?
One would assume.
> Cheers :-)
> P.D.- (more info) Please post the way you do to build the stuff.
I'm not sure exactly what I'm looking at here, but the build looks
nothing like CLFS. Obviously the search paths are wrong for the
toolchain, but I couldn't tell you if that was the only issue from the
info posted.

More information about the Clfs-support mailing list