Re: Bootstrapping gcc and then (if I could) glibc
Hello friendly Lluís,
2009/8/27 Lluís Batlle <viriketo@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@lists.cross-lfs.org) or gcc-help@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
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?
Cheers :-)
P.D.- (more info) Please post the way you do to build the stuff.
--
Héctor Orón
Reply to: