Feedback from using Crosstool-NG

Dan Wilder
Sun Jun 8 05:17:00 GMT 2014

A common corporate requirement is that toolchains should be built exclusively from material already situated on the corporate version control.  This provides complete traceability and insulates against things going unavailable at some time in the future, should it be required to rebuild a toolchain for example to change an option or fix a bug.

At WatchGuard Technologies we make use of Crosstool-NG, currently to build a gcc-4.8.2/glibc219 toolchain for x86 and PowerPC.  Our requirement is typical in that the build must rely only on materials previously enrolled in version control.

Fortunately it is very easy to do that, in part because of some changes submitted to Crosstool-NG by Bryan Hundven a few years ago.  A small wrapper script is required, to pre-position the material from the corporate version control, and a few configuration options are required.

If there is interest I'm happy to send to the list the current wrapper being used, and information as to the configration options required.  The wrapper could easily be modified for use with other version control systems.

Dan Wilder
From: [] on behalf of Thomas Petazzoni []
Sent: Saturday, June 07, 2014 10:23 AM
To: crossgcc maillist
Subject: Feedback from using Crosstool-NG


At Free Electrons, we regularly use Crosstool-NG, especially in our
embedded Linux trainings. I gave yet another training last week, and I
have a bunch of feedback I'd like to share with the Crosstool-NG
developers (most of it was already reported by Yann privately, but I
thought that sharing it publicly and by writing was probably better).

Comments are:

 * The current arm-unknown-linux-uclibcgnueabi sample does not build,
   because cloop-ppl 0.15.9 is no longer available online.

 * The strategy of Crosstool-NG to try gazillions of download locations
   and file extensions is silly, and actually harmful. In certain
   corporate environments, trying to download through ftp causes
   timeouts. Or even when http is used, when the server is not
   responding, it causes timeouts. I have seen cases where I had to
   wait more than one minute for a download to start, just because
   Crosstool-NG was trying dozens of possible locations before finding
   the relevant one. In Buildroot, we use one single URL for each
   tarball, and it works just fine.

 * The arm-unknown-linux-uclibcgnueabi sample is horribly old: gcc 4.4
   (while gcc 4.7 is close to end-of-like), uClibc 0.9.30 (we're at
   0.9.33), binutils 2.19 (we're at 2.24), gdb 7.1 (we're at 7.7).

 * It would be good to have a arm-unknown-linux-uclibcgnueabihf sample.

Surely, I could contribute patches to implement some of these things,
but I never managed to get around to use Mercurial, and since the
number of projects using it is so small, I don't really see the point
of learning :)


Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering

For unsubscribe information see

For unsubscribe information see

More information about the crossgcc mailing list