Cross Compiling Joys, Woes, and Insanity

[Kumba <kumba at gentoo dot org>]

Greetins all,

	As indicated by my subject, particularly the last word, I am beginning 
to wonder if I am losing my mind or not while trying to devise a script 
to build a cross-compiler toolchain.  Now I know there are many such 
scripts out there, most notably the one done by Dan Kegel.  The purpose 
of my script, however, is to try and integrate itself a little bit with 
Gentoo's portage system, and for the most part, the script works 
flawlessly.  However, the script aside, I have run into a bit of a brick 
wall in the actual cross-compiling process, most notably with our 
wonderful friend, Glibc.

	The way I've set my script up, there are 5 stages to building a 
cross-compiler:
	1. Unpack, configure && cp kernel headers to target rootfs
	2. Unpack && build binutils; Install to target rootfs
	3. Unpack && build gcc-core/bootstrap (a.k.a. C-Only compiler) and 
install it to the target rootfs
	4. Unpack && configure glibc, setting CC to be our "bootstrap" gcc 
cross-compiler.  Build and install to target rootfs.
	5. Recompile gcc for full support (minimum c,c++ langs)

	My script more or less does the first three steps flawlessly.  It's 
when it gets into the fourth step, glibc, is when the problems start to 
occur.  For reference, provided below is the Configure line passed to my 
bootstrap gcc compiler:

	CFLAGS="${MY_CFLAGS} -Dinhibit_libc" \
	../configure \
		--prefix=${CROSS_INSTALL}/${TARGETARCH} \
		--host=${MY_CHOST} \
		--target=${CROSS_CHOST} \
		--with-newlib \
		--disable-shared \
		--disable-threads \
		--enable-languages=c \
		--disable-multilib \
		--disable-nls \
		--enable-symvers=gnu \
		--enable-__cxa_atexit \
		--without-headers \

	This configure is consistent with what I have seen in other 
cross-compiling scripts, so I do not believe the problem is here.  I 
could be wrong, however.  Provided next is my glibc configure line:

	BUILD_CC="gcc" \
	CC="${CROSS_CHOST}-gcc" \
	AR="${CROSS_CHOST}-ar" \
	RANLIB="${CROSS_CHOST}-ranlib" \
	CFLAGS="-O2 ${CROSS_CFLAGS}" \
	../configure \
		--prefix=${CROSS_INSTALL}/${TARGETARCH} \
		--host=${CROSS_GLIBC_CHOST} \
		--build=${MY_CHOST} \
		--without-tls \
		--without-__thread \
		--enable-add-ons=linuxthreads \
		--enable-clocale=gnu \
		--enable-kernel=${MIN_KV} \
		--without-gd \
		--without-cvs \
		--disable-profile \
		--disable-debug \
		--with-headers="${CROSS_INSTALL}/${TARGETARCH}/include" \


	This too is more or less consistent with what I have seen in other 
cross-compiling scripts.  For the most part, I would say about 60% of 
glibc builds, from the look of things.

	Now I have been testing my script by attempting to compile an 
i686-pc-linux-gnu -> mips-unknown-linux-gnu cross-compiler.  About 
halfway, maybe more through glibc, I get the following error:

/home/crossdev/mips/lib/gcc-lib/mips-unknown-linux-gnu/3.3.2/../../../../mips-unknown-linux-gnu/bin/ld:/usr/obj/portage/crossdevbuild/glibc-2.3.2/buildhere/shlib.lds:220: 
syntax error

Line #220 of shlib.lds reads the following:
/home/crossdev/mips/lib/gcc-lib/mips-unknown-linux-gnu/3.3.2/../../../../mips-unknown-linux-gnu/bin/ld: 
cannot open crti.o: No such file or directory

Now this "error" occurs right after ld.so is compiled by glibc.  I am at 
a loss to understand why glibc looks for crti.o, I am not exactly sure 
on the origins of this file, but I believe glibc creates this file, so 
why glibc looks for a piece of itself baffles me.  I suspect perhaps 
that maybe this is because the generation of ld.so is complemented by 
the flags -lgcc -lgcc_eh being present on the gcc call itself.  Since 
libgcc was not built in my bootstrap compile, I feel this is the likely 
cause of the failure of my script.  I have not found a way around this 
error yet.  I even went as far as to strip the -lgcc -lgcc_eh flags from 
the ld.so compile line.  This did not change anything on i686.

	Feeling it is a bug on i686, I decided to try the same cross-compile on 
my sparc64 box, creating a sparc-unknown-linux-gnu -> 
mips-unknown-linux-gnu cross-compiler, which I might add I have 
sucessfully done in the past.  Using the same trick from i686, I went 
ahead and stripped -lgcc -lgcc_eh from the sparc attempt, because with 
sparc, if I leave those flags in play, I know will fail with an error 
like "-lgcc_eh not found".  Removing the lines allows sparc to compile 
*way* ahead of i686.  Sparc, unfortunately, dies here:

make -C ../io 
objdir=/usr/obj/portage/crossdevbuild/glibc-2.3.2/buildhere -f Makefile 
-f ../elf/rtld-Rules rtld-all rtld-modules='rtld-xstat64.os 
rtld-fxstat64.os rtld-open.os rtld-close.os rtld-read.os rtld-write.os 
rtld-lseek.os rtld-access.os rtld-fcntl.os rtld-getcwd.os 
rtld-readlink.os rtld-xstatconv.os'
/usr/obj/portage/crossdevbuild/glibc-2.3.2/buildhere/libc.a(strtoll.o)(.text+0x1a0): 
In function `__strtoll_internal':
: undefined reference to `__udivdi3'
/usr/obj/portage/crossdevbuild/glibc-2.3.2/buildhere/libc.a(strtoll.o)(.text+0x1c8): 
In function `__strtoll_internal':
: undefined reference to `__umoddi3'
/usr/obj/portage/crossdevbuild/glibc-2.3.2/buildhere/libc.a(strtoull.o)(.text+0x1a0): 
In function `__strtoull_internal':
: undefined reference to `__udivdi3'
/usr/obj/portage/crossdevbuild/glibc-2.3.2/buildhere/libc.a(strtoull.o)(.text+0x1c8): 
In function `__strtoull_internal':
: undefined reference to `__umoddi3'
collect2: ld returned 1 exit status
make[2]: *** 
[/usr/obj/portage/crossdevbuild/glibc-2.3.2/buildhere/elf/sln] Error 1
make[2]: *** Waiting for unfinished jobs....


The make continues for a few more lines, then finally dies.


	I have tried trudging through google seeking an answer to either of 
these problems, but so far have not had luck.  I have also not tried any 
other cross-compiling targets except for mips-unknown-linux-gnu fearing 
same or similar errors will occur.  So I have turned to this ML in the 
hopes someone here happens to know an answer to these problems, or 
notices something wrong in the way I am doing things and can recommend a 
fix.

	For reference, I am using the following packages:

glibc-2.3.2 (20031010 CVS Snapshot + gentoo patches)
gcc-3.3.2 [i686]
gcc-3.3.1 (20030927 CVS (on sparc)]
binutils-2.14.90.0.6
linux-2.4.21 headers (from linux-mips CVS)


	Please CC me on any replies to my question on this list, as I am not 
currently subscriber to it.  Any advice would be welcome.

Thanks,


--Kumba

--
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com