(Redirected from CodeSourcery)
Jump to navigation Jump to search

This page describes how to get a Toolchain, a build environment matching your target device's architecture, so you can cross-compile for that architecture.

General information

A toolchain is a set of system libraries, compilers and other tools which allow you to build (in our case, cross-compile) u-boot and the kernel for a target platform.

Cross-compile versus native

With quad 64-bit cores clocked at 1.5GHz it is feasible to build any code directly on the target machine. Usually though, modern x86 machines are clocked several times faster, often have more cores or threads available, and much more memory installed and much faster IO. It still makes sense to cross-compile in most cases, especially for building the kernel.

Our wiki is geared towards cross compilation, but if you do want to compile on the target machine directly, you can alter the build instructions from (typically):

make CROSS_COMPILE=arm-linux-gnueabihf-

to simply:


by trivially removing the CROSS_COMPILE argument.

Packaged versus standalone toolchain

These days, linux distributions package armhf, armel and aarch64 toolchains for you. A packaged toolchain will be kept up to date with your distribution, and should be available in your PATH without your intervention.

Standalone toolchains are big tarballs with a whole toolchain inside. This allows for user-local installation, but is not kept up to date with your distribution package management, and you need to add this toolchain to your PATH.

There should be little point in using a standalone toolchain, so use the version that comes with your distribution.

armhf versus armel

Around the mid 2010s, a new 32bit arm ABI (application binary interface) was introduced to make use of the floating point units on most modern ARM cores. This is called Hard-Float, for hardware-floating-point-unit. The newer ABI is now called armhf. Armhf has since become the go-to default.

Mixing armhf and armel ABIs between bootloader, kernel and rootfs should theoretically work, but your mileage may vary.

Throughout this wiki, we default to the hardfloat toolchain for armv7/32bit architectures.

Using armel with our wiki

If you are using an armel toolchain, then whenever you see something like:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-

You can just replace arm-linux-gnueabihf- with arm-linux-gnueabi-

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-

Installation as part of a distribution


ArmHF (32bit)

apt-get install gcc-arm-linux-gnueabihf


apt-get install gcc-aarch64-linux-gnu

Known issues/Caveats

Ubuntu 16.04 LTS (xenial xerus)

The gcc version in Ubuntu 16.04 (gcc version 5.4.0 20160609) bugs while compiling U-Boot:

{standard input}: Assembler messages:
{standard input}:323: Error: push/pop do not support {reglist}^ -- `pop {r0,r1,r2,r3,r4,r9,ip,pc}^'
scripts/ recipe for target 'arch/arm/cpu/armv7/sunxi/psci.o' failed

If you really wish to still use 16.04 today, you might need to get a standalone toolchain


yum install gcc-arm-linux-gnu


The crossdev tool[1] is the standard way of dealing with crosscompilers in Gentoo. Command line options are used to specify any arbitrary mix of different versions of the kernel headers, glibc, binutils and gcc. You can also use the -S option instead (to pick whatever is considered to be stable at the moment), but in this case the crosscompiler will be also upgraded as part of the regular distribution updates, which might be a bit annoying.

ArmHF (32bit)

Even though Gentoo normally uses armv7a-hardfloat-linux-gnueabi as the toolchain triplet on ARM, we can also use Debian alike arm-linux-gnueabihf variant in order to be able to use the compilation instructions from the linux-sunxi wiki as-is (without substituting the toolchain name).

emerge crossdev
crossdev --kernel =3.18 --libc =2.20-r2 --binutils =2.24-r3 --gcc =4.8.5 \
         --genv 'USE="-fortran -mudflap -nls -openmp multilib" EXTRA_ECONF="--with-cpu=cortex-a8 --with-float=hard"' -t arm-linux-gnueabihf


emerge crossdev
crossdev --kernel =3.18 --libc =2.21-r1 --binutils =9999 --gcc =4.9.3 \
         --genv 'USE="-fortran -mudflap -nls -openmp multilib -sanitize" EXTRA_ECONF="--enable-fix-cortex-a53-843419"' -t aarch64-linux-gnu

Note: binutils =9999 (fetch sources from git) should be replaced with =2.26 as soon as binutils 2.26 is added to portage. Such new binutils version is necessary for having a Cortex-A53 erratum 843419 workaround.


If you have one of the Allwinner SoC variants with an additional OpenRISC core (for example A31 and H3 have it), then you might want to also build an OpenRISC crosscompiler too:

emerge crossdev
mkdir -p /etc/portage/patches/cross-or1k-elf/gcc-5.2.0
cd /etc/portage/patches/cross-or1k-elf/gcc-5.2.0
crossdev --binutils =2.25.1-r1 --gcc =5.2.0 --libc = \
         --genv 'USE="cxx multilib -fortran -mudflap -nls -openmp -sanitize"' \
         -s4 -t or1k-elf

Please note that the upstream GCC does not support OpenRISC yet, so the OpenRISC code is still brewing in and we can solve this problem by just providing a patch for GCC in the /etc/portage/patches directory.

  1. The Gentoo website has undergone a major overhaul as of April 2015. While a backup of the old content is still available, it seems to have left the Gentoo Embedded Handbook in a non-functional state. You can still find a copy via The wiki article on Raspberry Pi Cross building might also be helpful.



Standalone toolchain installation


For the longest time, Linaro has been providing ready built toolchains for you to download.

Download a gcc-linaro-<major>.<minor>-<year>.<month>.tar.xz file and untar it.

You will find a bin directory in there. Temporarily add it to the environment you are building from:

export PATH="$PATH":/home/user/folder/gcc-linaro-arm-linux-gnueabihf-*_linux/bin/

Legacy sunxi kernel

If you, for whatever reason, still want to use the 2012-2014 era legacy 3.4 sunxi kernel, it makes sense to use the 4.9.4 linaro toolchain.

The 4.8 linaro toolchain was known to have issues when building the sunxi kernel.


Bootlin also provices glibc / musl / uclibc based toolchains.