• 20080905: Released 1.2.3 (bug-fix)
• 20080826: Released 1.2.2 (bug-fix)
• 20080810: Released 1.2.1 (bug-fix)
• 20080720: Released 1.2.0
• 20080620: Released 1.1.3a (bug-fix)
• 20080526: Released 1.1.2 (bug-fix)
• 20080515: Released 1.1.1 (bug-fix)
• 20080504: Released 1.1.0
• 20080411: Martin GUY jumped in! Welcome!
• 20080220: Robert P. J. DAY joined development! Welcome on board, now a team of two!
• 20080116: Released 1.0.0
• 20070917: Released 0.3.2
• 20070901: Released 0.3.1
• Older news

crosstool-NG aims at building toolchains. Toolchains are an essential component in a software development project. It will compile, assemble and link the code that is being developed. Some pieces of the toolchain will eventually end up in the resulting binary/ies: static libraries are but an example.

So, a toolchain is a very sensitive piece of software, as any bug in one of the components, or a poorly configured component, can lead to execution problems, ranging from poor performance, to applications ending unexpectedly, to mis-behaving software (which more than often is hard to detect), to hardware damage, or even to human risks (which is more than regrettable).

Toolchains are made of different pieces of software, each being quite complex and requiring specially crafted options to build and work seamlessly. This is usually not that easy, even in the not-so-trivial case of native toolchains. The work reaches a higher degree of complexity when it comes to cross-compilation, where it can become quite a nightmare...

Some cross-toolchains exist on the internet, and can be used for general development, but they have a number of limitations:

• they can be general purpose, in that they are configured for the majority: no optimisation for your specific target,
• they can be prepared for a specific target and thus are not easy to use, nor optimised for, or even supporting your target,
• they often are using aging components (compiler, C library, etc...) not supporting special features of your shiny new processor;

On the other side, these toolchains offer some advantages:

• they are ready to use and quite easy to install and setup,
• they are proven if used by a wide community.

But once you want to get all the juice out of your specific hardware, you will want to build your own toolchain. This is where crosstool-NG comes into play.

There are also a number of tools that build toolchains for specific needs, which are not really scalable. Examples are:

• buildroot whose main purpose is to build root file systems, hence the name. But once you have your toolchain with buildroot, part of it is installed in the root-to-be, so if you want to build a whole new root, you either have to save the existing one as a template and restore it later, or restart again from scratch. This is not convenient,
• ptxdist, whose purpose is very similar to buildroot,
• other projects (openembedded for example), which is again used to build root file systems.

crosstool-NG is really targetted at building toolchains, and only toolchains. It is then up to you to use it the way you want.

With crosstool-NG, you can learn precisely how each component is configured and built, so you can finely tweak the build steps should you need it.

crosstool-NG can build from generic, general purpose toolchains, to very specific and dedicated toolchains. Simply fill in specific values in the adequate options.

Of course, it doesn’t prevent you from doing your home work first. You have to know with some degree of exactitude what your target is (archictecture, processor variant), what it will be used for (embedded, desktop, realtime), what degree of confidence you have with each component (stability, maintainability), and so on...

NOTE: crosstool-NG is a rewrite of the original crosstool by Dan Kegel. Big thanks to him for putting his original work on-line!

It’s quite difficult to list all possible features available in crosstool-NG. Here is a list of those I find important:

• kernel-like menuconfig configuration interface
  • widespread, well-known interface
  • easy, yet powerful configuration
• support for alternative components in the toolchain
  • uClibc- or glibc-based toolchain supported right now!
  • others easy to implement
• patch repository for those versions needing patching
  • support many versions of the toolchain components
  • support for custom (understand local) patch repository
• different threading models
  • NPTL
  • linuxthreads
• support for both soft- and hard-float toolchains
• debug facilities
  • native and cross gdb, gdbserver
  • debugging libraries: dmalloc, more to come
  • restart a build at any step
• sample configurations repository usable as starting point for your own toolchain

You can:

• browse the code on-line
• get released versions there: http://ymorin.is-a-geek.org/download/crosstool-ng/
• check-out the development stuff from svn at: http://ymorin.is-a-geek.org/svn/crosstool-ng/trunk
• developer access is available via svn+ssh://ymorin.is-a-geek.org/svn/crosstool-ng/ on port 2222 (port 22 is filtered due to massive attacks)

Now test with:

./configure --prefix=/some/place
make
make install
export PATH="${PATH}:/some/place/bin"
cd /your/development/directory
ct-ng help
ct-ng menuconfig
ct-ng build

Note 1: If you call ct-ng --help you will get help for make(2). This is because ct-ng is in fact a make(2) script. There is no clean workaround for this.

Note 2: If you elect to build a uClibc-based toolchain, you will have to pass a config file for uClibc. I hope to be able to remove this necessity in the future if it happens to be possible. As for the kernel, if you elect to use one of the deprecated methods (copy or sanitised) instead of the new headers_install in recent kernels, you will also have to pass a kernel configuration file.

Here is the list of target architectures crosstool-NG currently supports:

(*) Support for ia64 is limited to old versions of gcc and glibc for now.
(+) Support for Super-H is clumsy at best, but infrastructure is there.
(~) OpenRISC is present as contributed code only (see ./configure --with-contrib=list).

Here are some of the toolchains that were successfully built with crosstool-NG. Of course, there are many other working combinations, but I focus on making the latest versions working.

Note: The above table reflects the state of the SVN trunk at the time it (the table) was built. And it is periodically refreshed, every hour.
Note 2: If you have other working combinations, please send in the config file(s), they’ll get added to the samples repository in crosstool-NG, so that every one can benefit from it. As a bonus, the above table will be automatically updated with your name!
Note 3: This table is directly accessible here.

Here are a few hints on how to ask for help:

Problem	Where/whom to ask for help
– A component (gcc, binutils, C library...) does not build. – Generated files do not work.	Send a mail To: The crossgcc mailing list
– crosstool-NG breaks. – You have improvements and/or fixes for crosstool-NG or this WiKi page.	Send a mail To: Yann E. MORIN (myself) and CC: The crossgcc mailing list
– You find crosstool-NG usefull. – You succeeded in your project partly thanks to crosstool-NG.	Drop me a little explanation (without breaking your company’s rules, if any), and I’ll post your feedback on this page.
– You need personal assistance. – You demand that I add a feature you need. – You demand that I answer your mails instantly.	Well, I program crosstool-NG on my free time, on a voluntary basis, without being paid (so far), and mostly because I needed it. It is based on code freely contributed by many people over many years. How can you demand anything? If even you offered payement...
– You are a nice girl from Russia (or wherever), and you have pictures of your big breast to show me.	Send mail To: /dev/null

As I said above, I can’t test on all platforms. Anyone volunteering to test on alternate platforms I haven’t access to (or even ones I have access to) is welcome to report success/failure on those platforms. Thank you!

Alternatively, I need a faster, more reliable machine. If you have at least a dual-core desktop with 2GiB RAM and a 80GiB HDD, and you were to trash it: simply don’t. This machine will be used solely for crosstool-NG development, and building the toolchains. I would pretty well do with only an ssh access to the machine, if you also offered to host it!

This is an informal, somewhat-unordered TODO list:

• add a test suite for the generated toolchains
  • test-build is here
  • needs to test generated toolchains (needs real HW or emulator)
• add more debug facilities
• canadian build
  • rearrange samples directory
• add other hosts and targets support
  • cygwin
  • bare metal
• add and test more arches
• create a collection of standard targets [on-going in sub-directory samples/]
• ...

Adding support for multilib is not quite easy. Take the ARM architecture for example. We can support:

• ARM (32 bits) and ARM26 (32 bits, only 26-bit memory space)
• ARM or Thumb opcodes
• OABI vs. EABI
• big and little endianness
• software floating point or hardware FP for FPA/VFP/Maverick FPUs
• different instruction sets: ARMv[3456]
• etc..

That would require a C library compiled for each of the supported combinations (so for ARM we’d have up to 256 C libraries compiled). Not telling how to guess the afore-mentioned combinations (not all architectures have all combinations)...

So for now, that’s a no-no, and the solution is to build one toolchain for each targetted sub-architecture, differentiating each toolchain with the vendor string.

That one is tricky as well, but we should be able to overcome most of the problems lying in front of us...

Let’s take the worst case, where build != host != target. So for a compiler built on build, running on host, generating code for target:

	We need a compiler that...
	runs on...	and generates code for...	to build...	that runs on...	and generates code for...
1	build	build	X-binutils and X-compiler	build	host
1	build	build	X-binutils and X-compiler	build	target
2	build	host	C library (and helpers)	host	N.A.
3	build	target	C library (and helpers)	target	N.A.
	to build a toolchain that...
	runs on...	generates code for...	to build...	that runs on...	and generates code for...
4	host	target	our very-own software	target	N.A.

As you see, generating a full canadian cross-compiler is no easy task. We will assume that the native compiler on the first two lines (1) is available on your system.

Then, the two cross-compilers for build→host (2) and build→target (3) are assumed to be present. They most probably will be build using crosstool-NG!

Finally, we would be able to buildthe cross-compiler we’re interested in (4).

Note that it would be very complex to provide options for those compilers in a single config menu (it would almost triple the menu items!). Thus, we’d need to configure them as separate compilers.

Once the canadian build proper works, we could have a wrapper script take the three configurations, and build the three toolchains in turn. But that would be only for convenience, as we’d still need to provide correct configuration for every compilers.

So here is a list of things to do, in order:

1. build a cross-compiler for host to run on build
2. build a cross-compiler for target to run on build
3. build a canadian cross-compiler for target to run on host

I have no Windows machine on which I can test. I have a Windows license, but I don’t use it. So I have to find a way to have a Windows machine up and running.

My old laptop could do the job, but I’m using it. Qemu is a solution, but I’m afraid of the speed impact. I don’t want Windows on my main machine, because I’d have to reboot each time I want to test something. My girlfriend’s computer is, well, not an option (she’d argue with my using it: “You’re gonna break things!”, “I want to see my mail RIGHT NOW!”, and the likes ). My server is, well, not available. Could I make an Xbox boot XP?

Plus the fact that, running only Linux on my computers (my girlfriend’s PC is not considered as being part of my conputers ) means I’ve forgotten the ways of Windows (Control center, explorer, etc...)

I’ll have to think about it...

MacOS X as a build system seems to have issues with the configurator: you must pass KBUILD_NO_NLS=1 on the make command line, as to not configure the internationalisation. Thanks go to Allan Clark for the patch.

Also, some of the tools there are not up-to-date with the one required by crosstool-NG:

• the bash version there (2.05b) doesn’t support set -E. Only starting with 3.0 does bash support set -E. I have no fix yet.
• the sed version does not understand some flags (-r, for extended regular expressions, is not accepted). So the install fails.
• the date command does accept nanoseconds format %N.
• seems also that bash is limited to doing 32-bit maths, when I need 64-bit maths (cause of nanoseconds).

I have been able to build a java cross-compiler for some architectures starting with 1.0.0. Thorough testing is lacking, though. Any taker?

Fortran is supported as of release 1.1.0. A Fortran cross-compiler was built for some architectures, but was not tested due to my ignorance of this language. Any taker?

No comment so far.

No comment so far.

No comment so far.

Hahaha! You must be kidding!

There are patches floating around that add other frontends to gcc. If anyone reading this page has a need for one of those language, and succeeds in building a toolchain with crosstool-NG, I’d appreciate being sent a patch!

The Pascal frontend to gcc (GPC) is maintained there. Unfortunately, it hasn’t changed since March 2005, when it was ported to gcc-3.4.4, and there has been no other release of GPC since then.

Mercury is a declarative logic/functional language developped at the University of Melbourne (or so I think). Latest official release is 0.13.1, dated 20061201, available for both gcc-3.4.x and gcc4.1.x. However, there are ROTD (Release Of The Day) every day since then, available againt gcc-3.4.x only. The developpers mailing list seems quite active.

GHDL is a complete VHDL simulator, using the GCC technology, maintained there. The latest release for GHDL is quite recent (April 2007), and is available for gcc-4.1.2 (not for more recent versions), but the SVN repository seems live. GHDL requires a native GNAT ADA compiler to be built.

The COBOL frontend, maintained there, is still quite young (started October 2007), but has had a full-time developper for the first six months of its life. The posts to the developpers ML are sparse, but they aim at a first basic subset by June 2008.

As stated on their site, “the intention of GNU Modula-2 is to provide a production modula-2 front end to GCC”. The frontend interfaces with gcc-4.1.2 only.

Here are some snapshots of crosstool-NG in action:

00-main.jpg	01-paths-misc.jpg	02-target.jpg	03-toolchain.jpg	04-kernel.jpg	05-gmp-mpfr.jpg
06-binutils.jpg	07-c-compiler.jpg	08-c-library-uclibc.jpg	09-c-library-glibc.jpg	10-debug.jpg	11-gdb.jpg

And here is a log of a successfull run:

[INFO ]  Build started 20080701.105319
[INFO ]  Checking environment sanity
[WARN ]  GREP_OPTIONS screws up the build. Resetting.
[INFO ]  Building environment variables
[EXTRA]  Preparing working directories
[WARN ]  You did not specify the build system. That's OK, I can guess...
[EXTRA]  =================================================================
[EXTRA]  Dumping internal crosstool-NG configuration
[EXTRA]    Building a toolchain for:
[EXTRA]      build  = i686-pc-linux-gnu
[EXTRA]      host   = i686-pc-linux-gnu
[EXTRA]      target = armeb-unknown-linux-uclibcgnueabi
[EXTRA]  Dumping internal crosstool-NG configuration: done in 0.07s (at 00:00)
[INFO ]  =================================================================
[INFO ]  Retrieving needed toolchain components' tarballs
[INFO ]  Retrieving needed toolchain components' tarballs: done in 0.06s (at 00:00)
[INFO ]  =================================================================
[INFO ]  Extracting and patching toolchain components
[INFO ]  Extracting and patching toolchain components: done in 0.11s (at 00:01)
[INFO ]  =================================================================
[INFO ]  Checking C library configuration
[EXTRA]    Munging uClibc configuration
[INFO ]  Checking C library configuration: done in 0.04s (at 00:01)
[INFO ]  =================================================================
[INFO ]  Installing kernel headers
[EXTRA]    Installing kernel headers
[EXTRA]    Checking installed headers
[INFO ]  Installing kernel headers: done in 13.45s (at 00:14)
[INFO ]  =================================================================
[INFO ]  Installing GMP
[EXTRA]    Configuring GMP
[EXTRA]    Building GMP
[EXTRA]    Checking GMP
[EXTRA]    Installing GMP
[INFO ]  Installing GMP: done in 80.29s (at 01:34)
[INFO ]  =================================================================
[INFO ]  Installing MPFR
[EXTRA]    Configuring MPFR
[EXTRA]    Building MPFR
[EXTRA]    Checking MPFR
[EXTRA]    Installing MPFR
[INFO ]  Installing MPFR: done in 70.81s (at 02:45)
[INFO ]  =================================================================
[INFO ]  Installing binutils
[EXTRA]    Configuring binutils
[EXTRA]    Building binutils
[EXTRA]    Installing binutils
[INFO ]  Installing binutils: done in 53.27s (at 03:39)
[INFO ]  =================================================================
[INFO ]  Installing C library headers
[EXTRA]    Copying sources to build dir
[EXTRA]    Applying configuration
[EXTRA]    Building headers
[EXTRA]    Installing headers
[INFO ]  Installing C library headers: done in 4.68s (at 03:43)
[INFO ]  =================================================================
[INFO ]  Installing static core C compiler
[EXTRA]    Configuring static core C compiler
[EXTRA]    Building static core C compiler
[EXTRA]    Installing static core C compiler
[INFO ]  Installing static core C compiler: done in 91.11s (at 05:14)
[INFO ]  =================================================================
[INFO ]  Installing C library
[EXTRA]    Copying sources to build dir
[EXTRA]    Applying configuration
[EXTRA]    Building C library
[EXTRA]    Installing C library
[INFO ]  Installing C library: done in 97.43s (at 06:52)
[INFO ]  =================================================================
[INFO ]  Installing final compiler
[EXTRA]    Configuring final compiler
[EXTRA]    Building final compiler
[EXTRA]    Installing final compiler
[EXTRA]    Moving improperly installed gcc libs to sysroot
[INFO ]  Installing final compiler: done in 247.67s (at 10:59)
[INFO ]  =================================================================
[INFO ]  Installing binutils for target
[EXTRA]    Configuring binutils for target
[EXTRA]    Building binutils' libraries (libiberty bfd) for target
[EXTRA]    Installing binutils' libraries (libiberty bfd) for target
[INFO ]  Installing binutils for target: done in 76.79s (at 12:16)
[INFO ]  =================================================================
[INFO ]  Installing GMP for the target
[EXTRA]    Configuring GMP
[EXTRA]    Building GMP
[EXTRA]    Installing GMP
[INFO ]  Installing GMP for the target: done in 53.72s (at 13:10)
[INFO ]  =================================================================
[INFO ]  Installing MPFR for the target
[EXTRA]    Configuring MPFR
[EXTRA]    Building MPFR
[EXTRA]    Installing MPFR
[INFO ]  Installing MPFR for the target: done in 29.32s (at 13:39)
[INFO ]  =================================================================
[INFO ]  Installing sstrip
[EXTRA]    Building sstrip
[EXTRA]    Installing sstrip
[INFO ]  Installing sstrip: done in 0.23s (at 13:40)
[INFO ]  =================================================================
[INFO ]  Installing dmalloc
[EXTRA]    Configuring dmalloc
[EXTRA]    Building dmalloc
[EXTRA]    Installing dmalloc
[INFO ]  Installing dmalloc: done in 15.60s (at 13:55)
[INFO ]  =================================================================
[INFO ]  Installing D.U.M.A.
[EXTRA]    Copying sources
[EXTRA]    Building libraries 'libduma.a libduma.so.0.0.0'
[EXTRA]    Installing libraries 'libduma.a libduma.so.0.0.0'
[EXTRA]    Installing shared library link
[EXTRA]    Installing wrapper script
[INFO ]  Installing D.U.M.A.: done in 1.32s (at 13:57)
[INFO ]  =================================================================
[INFO ]  Installing cross-gdb
[EXTRA]    Configuring cross-gdb
[EXTRA]    Building cross-gdb
[EXTRA]    Installing cross-gdb
[INFO ]  Installing cross-gdb: done in 130.73s (at 16:07)
[INFO ]  =================================================================
[INFO ]  Installing native gdb
[INFO ]    =================================================================
[INFO ]    Installing ncurses library
[EXTRA]      Configuring ncurses
[EXTRA]      Building ncurses
[EXTRA]      Installing ncurses
[INFO ]    Installing ncurses library: done in 92.71s (at 17:40)
[EXTRA]    Configuring native gdb
[EXTRA]    Building native gdb
[EXTRA]    Installing native gdb
[INFO ]  Installing native gdb: done in 266.49s (at 20:34)
[INFO ]  =================================================================
[INFO ]  Installing gdbserver
[EXTRA]    Configuring gdbserver
[EXTRA]    Building gdbserver
[EXTRA]    Installing gdbserver
[INFO ]  Installing gdbserver: done in 8.51s (at 20:42)
[INFO ]  =================================================================
[INFO ]  Installing strace
[EXTRA]    Configuring strace
[EXTRA]    Building strace
[EXTRA]    Installing strace
[INFO ]  Installing strace: done in 19.90s (at 21:02)
[EXTRA]  Installing the populate helper
[EXTRA]  =================================================================
[EXTRA]  Creating toolchain aliases
[EXTRA]  Creating toolchain aliases: done in 0.00s (at 21:02)
[INFO ]  Removing installed documentation
[INFO ]  Build completed at 20080701.111421
[INFO ]  (elapsed: 21:02.59)
[EXTRA]  Compressing log file

• On 20080826.0106+0200, Chris Hinshaw writes:

Thank you for making a non-trivial task simple. CT-NG is an excellent tool
and extremely easy to use. I have been using it to create toolchains for the
405 and it is an unbelievable time saver. Very well designed and
implemented.

Thank you,
Chris Hinshaw