Cross Toolchain for Raspberry Pi

Cross Toolchain for Raspberry Pi

Unglücklicherweise ist dieser Eintrag noch nicht ganz fertig, bitte habt ein wenig Geduld.

Unfortunately this entry is not yet finished – stay tuned.

Short Guide

If you are looking for a toolchain for cross-compiling software for the Raspberry Pi, you will most probably end up at the official tools repository.

For sure, you are an up-to-date and security-conscious developer and therefore you may be frozen-in-terror when you see that those toolchains are three to seven years old.

In the following I will therefore describe how you can easily create your own modern cross-toolchain for the Raspberry Pi.


At first, clone the latest crosstool-ng repository and enter the newly created directory

git clone
cd crosstool-ng

By invoking ./bootstrap we generate the necessary generator files (for ./configure, alternatively you can simply download the latest release which is pre-configured) by the following commands

mkdir crosstool-ng
tar xvjf crosstool-ng-1.23.0.tar.bz2 -C crosstool-ng --strip-components=1
cd crosstool-ng

Install crosstool-ng on your system by the following commands

./configure --prefix=/usr/local
sudo make install

Create and go into a newly created directory where you want the toolchain

cd ..
mkdir rpi-toolchain
cd rpi-toolchain
# ct-ng list-samples
ct-ng armv6-rpi-linux-gnueabi     # RaspberryPi 1
ct-ng armv7-rpi2-linux-gnueabihf  # or: RaspberryPi 2
ct-ng armv8-rpi3-linux-gnueabihf  # or: RaspberryPi 3
ct-ng build

Now, be patient – compilation may take some hours!

Continue in case of errors

Instead of ct-ng build, for the case that something goes wrong, I suggest to activate logging of the successful steps like this

CT_DEBUG_CT_SAVE_STEPS=1 ct-ng build

In case of an error, you will see a message like this

[ERROR]  >>  Build failed in step 'Installing cross-gdb'

You can then (after fixing the root case) continue after the last successful:

ct-ng <stepname>+

Detailed Guide

If you are one of those guys looking to the more detailed answers: here they are!

Choosing the right Glibc

Ever heard that a executable linked to a Glibc version that does not exactly fit the one which is installed on your target may cause a lot of problems? You heard right – at least if you are going to link Glibc statically.

That being said, please never ever link Glibc statically!

Glibc is mostly backwards-compatible, meaning that if you link your software dynamically to an older Glibc version, it will – in most cases – work even if the installed Glibc on your target is newer. Otherwise you would have a lot of fun after updating your system.

Linking dynamically as the portable way is contrary to what you would expect maybe, statically linked libraries are in general a wide-spread way to prevent compatibility problems. Easily because the libraries are tied to your software – so what should possibly go wrong?

Glibc is not designed to be linked statically, even if you do so it will still use some parts of the systems Glibc, which is then maybe not compatible.

If you really want to link the C standard library statically, then please use uClibc! On the other hand, it is perfectly fine to link e.g. libstdc++ statically.

Which Glibc Version does my Target have?

pi@whiterover:/lib/arm-linux-gnueabihf $ sudo /lib/arm-linux-gnueabihf/ 
GNU C Library (Debian GLIBC 2.24-11+deb9u3) stable release version 2.24, by Roland McGrath et al.
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
Compiled by GNU CC version 6.3.0 20170516.
Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al
For bug reporting instructions, please see:
Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email