This is the mail archive of the
crossgcc@sources.redhat.com
mailing list for the crossgcc project.
See the CrossGCC FAQ for lots
more information.
Cross Compiling Joys, Woes, and Insanity
- From: Kumba <kumba at gentoo dot org>
- To: crossgcc at sources dot redhat dot com
- Date: Wed, 22 Oct 2003 20:01:42 -0400
- Subject: Cross Compiling Joys, Woes, and Insanity
- Reply-to: 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