[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: