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

[Joe Ciccone]

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.