Building and Testing gcc/glibc cross toolchains
Note: This page is out of date.
See Crosstool-NG for a more
up to date toolchain script.
Note: be sure to read crosstool-howto.html; that's
the real doc.
Building a gcc / glibc cross-toolchain for use in embedded systems development
used to be a scary prospect, requiring iron will, days if not weeks of effort,
lots of Unix and Gnu lore, and sometimes willingness to take dodgy shortcuts.
This is a problem not only for individual users, but also for the gcc project
as a whole, since the gcc team relies
on users to test upcoming releases of gcc, and the difficulty of
building the toolchain for embedded targets restricted the number
of people able to help with the testing.
At Ixia, I had been maintaining a toolchain by starting with a commercial
free embedded linux toolchain, and overlaying it with newer versions
compiled from scratch as needed to fix problems. This became harder to
maintain as time went on.
After some months of frustration, it became clear we needed an
easy way to build and test gcc/glibc cross-toolchains from scratch.
Looking around, I realized that Bill Gatliff's
crossgcc FAQ and build script,
what most of the community used to build cross-compilers,
was almost what I needed, so I rolled up my sleeves and:
I call my updated script and associated patches 'crosstool'.
It's fairly easy to use and can be run unattended as part of an automatic build process,
and should go a long way towards making it easier for the
average developer to get started with gcc cross-compilers and help test
new releases of gcc.
- made darn sure it worked properly for ppc and gcc-2.95
- removed newlib support so I could focus on glibc more easily
- updated it to handle gcc-3.2.x, gcc-3.3.x, and gcc-3.4.x, since I wasn't sure which of those I would need
- enhanced it to automatically download the source tarballs and apply the minimal
set of patches needed to successfully build
- enhanced it to support all CPU types supported by glibc, since that was easy and was a good test of the script
- added support for running the gcc and glibc regression test suites, since at Ixia we need regression tests for everything we ship
- documented how to run dejagnu regression tests remotely, since that's how to test gcc on a small embedded platform, and the dejanu documentation is misleading and incomplete
- documented how to set up a chroot jail that allows remote login, since a chroot jail is the easiest way to test alternate versions of glibc, and there weren't any good howto's on the subject
- added support for building userland (for now, just busybox, ncurses, libnet, and libpcap) with
the new toolchain (see --builduserland option to all.sh) so you
can test even if you don't have userland apps compatible with the
You can see from the build matrix included in the buildlogs directory
of the crosstool tarball
that many combinations of CPU, gcc, glibc, and Linux produce toolchains
which can in fact compile user programs and the Linux kernel.
You can also see which combinations don't work, and by clicking on
their entries in the matrix, you can see the last 300 lines of
the build log, including the error that stopped the toolchain or kernel build.
(I used to have test results here for some embedded processors, but they're
a bit out of date.)
Here are a few success reports from other users:
Actual comments from happy users:
- Leif Huhn said he
used crosstool to generate a gcc3.2.3-glibc2.2.5 / arm-unknown-linux-gnu toolchain
which successfully compiles static binaries for the Zaurus 5600.
- Several people
say they've used crosstool to generate a gcc3.2.3-glibc2.2.5 / mipsel-linux toolchain
for the BCM4710 processor that powers the Linksys WRT54 Wireless Router.
- Dave Hylands
had to add some patches, but reported success using crosstool to generate
a gcc-2.95.3-glibc-2.2.2 / armv4b-linux big endian ARM toolchain.
- "Thanks for crosstool, it's a big time saver. I used demo-ppc405.sh
on Red Hat Enterprise Linux 3 ... With this compiler I'm able to compile
and boot a 2.4.19-rc3-based kernel on a PowerPPC 440 board."
- "Thanks for crosstool! It's been some time since I had
to build a cross-compiler, but I remember it being a pain. Your tool
makes it almost effortless."
- "Dan, your tool is full of Ass Kicking Goodness!(tm)!"
- "Thank you!! If I were female, at this point I would
offer to have your baby."
- "Thanks again for crosstool. It has been a wonderful oasis in the
turbulent sea of cross tool bits."
- "You have my utmost respect and awe. Your very careful work saved me
untold hours of work and search & read time."
- "Thank you so much for writing crosstool. Years ago, I spent ages
setting up a gcc cross-compiler, and was looking at doing so again
with dread (especially an unusual cygwin->Linux cross-compiler).
With crosstool, I was up and running after a single, automated, overnight
build -- I really didn't think it would work, as it seemed too good to
be true. You are an absolute angel. Thank you."
Dan Kegel is a software engineer currently employed by
He has been programming since 1978,
and mentoring intern programmers since 1994.
He served on the JSR-51
committee which helped add nonblocking I/O and file locking to the Java platform.
His web site "The C10K Problem"
is well-known among a small circle of internet server programmers, and his
essay "The Case for Linux in Universities"
has been translated into Spanish, Hindi, and Telugu.
He maintains lalugs.org
as a service to the Los Angeles Linux community.
He thanks his wife Liz Fuller for her support and patience during his periodic save-the-world quests,
Ixia for sponsoring the first four
months of this work, Bill Gatliff for the original script, Kaz Kojima
and Daniel Jacobowitz for supplying patches on the spot to solve various
problems, and the many crosstool users who have submitted bug reports,
fixes, and enhancements.
Last Change 7 Dec 2006
The latest copy of this document can be found at kegel.com/crosstool
Portions Copyright by Ixia, 2003
Portions Copyright by Google, 2003-2006
Crosstool is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
[Return to www.kegel.com]