CrossToolchain Roadmap

This document describes cross-toolchain plans and build-methods in Debian. This subject has been somehwat controversial with cross-toolchain and gcc maintainers disagreeing about how to proceed. This page tries to record things that are agreed as well as list proposals which may or may not come to pass. The objective is cross-toolchains released in Stretch.

Cross-Toolchain controversy

gcc cross-compilers can be built with or without multilib support, and either 'standalone' or with foreign-arch dependencies 'multiarch-built' (wdotap). The possibilities are described in full on ToolChain/Cross.

wdotap toolchains packages were uploaded to the archive in October 2014. The gcc maintainer objected to these, filing the tech committee bug (771070) below, and removing the support for those builds in gcc packaging (resulting in 766708). The cross-toolchain team continues to maintain the wdotap support as patches in the cross-gcc package.

At FOSDEM 2015 (Feb) the Tech Ctte asked Wookey and Matthias to meet and see if they could agree a way to proceed such that a ruling (on 771070) was not needed. A meeting tool place at Linaro Connect on 9th Feb, with Matthias Klose/doko (gcc maintainer), Adam Conrad/infinity (glibc maintainer), Wookey (cross-gcc maintainer), and Ian Campbell (Referee/Witness/Scribe). The full notes from that are at ToolChain/Cross/Connect2015meeting.

The following actions were agreed and reported to the Tech Ctte:

Since then these things happened:

The standalone gcc-5-cross compiler packages produce the same binaries as cross-gcc-5-* wdotap builds so they cannot co-exist in the archive.


Development occurs at the cross-toolchain Alioth group:

In the debian archive things are arranged like this:

Future cross-toolchain implementation (currently experimental)

Debian provided basic cross-toolchain support in the archive from November 2014 onwards. Previously this had only been available from external repositories.

These are generally built to run on fast architectures (amd64, ppc64el, arm64), and target all reasonably popular architectures (arm64, armel, armhf, powerpc, ppc64, i386, amd64, mips, mipsel, mips64el).

They will be automatically installed (by the magic of multiarch) if you enable the architecture you are building for, and install build-essential for a target architecture, or a package which directly depends on gcc-for-host.

!Note the BUILD architecture is the machine you are building _on_. the HOST architecture is the one you are building _for_

Installation concepts for experimental

To cross-build (or install cross toolchains) you will need to enable multiarch for the architecture you are building for (the HOST arch) (unless targetting an architecture that is not in Debian, in which case the cross-toolchain will be installable without any foreign-arch packages).

dpkg --add-architecture armhf
apt-get update

Use the debian architecture name to install toolchains (or cross-toolchains)

apt-get install -a<arch> build-essential


apt-get install -aarmhf build-essential

Note that the toolchains thus installed must be used as <triplet>-gcc, for both native _and_ cross usage. i.e. x86_64-linux-gnu-gcc for the native compiler on amd64, and arm-linux-gnueabihf-gcc for the cross-compiler targetting armhf.

Plain 'gcc' will (probably) not be installed.

Which packages are what?

Packages which need a particular version of gcc should build-depend on gcc-4.9-for-host Packages which also need the build-arch gcc when cross-building, should build-depend on gcc-for-build (for the default version) or gcc-4.9-for-build (to get 4.9 specifically).

Similar packages exist for g++, cpp, gfortran, binutils and pkg-config.

Installing build-dependencies

apt-get build-dep -a <arch> <package>


apt-get build-dep -a armhf util-linux

If the build-deps are not installable in this way (usually due to un-multiarched packages in the dependency tree), then use dpkg-checkbuilddeps and apt-get install to manually insert the right packages.

Information for package maintainers

In the pre-multiarch-crosscompiler world (jessie and earlier) a package could run 'gcc' and expect to get the compiler targetting the native arch and running on the native arch (e.g amd64,amd64). And it could build-depend on 'gcc-4.7' to get an older compiler installed. However There was no way to depend on a particular compiler version and have that version of the cross-compiler installed, so this scheme made any package needing a particular gcc version uncrossbuildable (without a lot of faffing).

In stretch build-essential implicitly depends on the compiler for the HOST architecture (which is the architecture you are building _for_) via 'gcc-for-host'. This is the default compiler, which must be run specifying the TARGET architecture (the one you want to build code for), i.e. as x86_64-linux-gnu-eabi-gcc. Don't call 'gcc' as it may not do the right thing, or work at all.

Packages that need a specific version of the compiler can now depend on 'gcc-<version>-for-host' and will get the <triplet>-gcc for the (HOST) architecture that the build is targetting.

See the multilib section for info on why it is recommended to always call the compiler as <triplet>-gcc

How does this _really_ work

Details of the gcc interface and metapackage design are in

Appropriate info needs extracting to here