Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• ToolChain/Cross/Roadmap

CrossToolchain Roadmap

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:

• cross-toolchain-base to use binutils-cross. Optional, not required. [Adam]
• Somebody to get kernel lack of debian dir in linux-source pkg fix. [Adam]
• cross-toolchain-base to move to VCS somewhere and be part of an Alioth group. [Doko to talk to Dmitri] [ALL to join crosstoolchain alioth project]
• Prove that cross-toolchain-base works for one architecture which has multilib. e.g. powerpc. [Adam]
• Make it work for all architectures. Produces libc-$ARCH-cross for all arches we care about. [Adam]
• Wookey's cross-gcc switched to depend on libc-$ARCH-cross instead of libc:$ARCH. Produces cross-gcc-X.Y-$ARCH.dsc which are uploaded one per architecture. [Wookey]
• Everyone agrees that cross-toolchain-base is halfway sane, solves Adam+Doko's complaints and Wookey is prepared to work with it so long as he doesn't have to maintain it.

Since then these things happened:

• wdotap build patches were ported to gcc-5, and cross-gcc updated to support more than one major compiler version in April.

• cross-gcc-5-* wdotap builds (amd64->arm64) were uploaded to NEW on (and are still there) (2015-04-28)

• gcc-defaults 137 which conflicted with cross-gcc-5-* was uploaded (to make cross-gcc-5-* uninstallable) https://tracker.debian.org/news/681047 Debianbug:783908

• Multilib support was added to the cross-gcc package in May (2015-05-12) mail to debian-cross

• cross-toolchain-base (providing *-cross packages) was uploaded to NEW, then unstable the next day (2015-05-19)
• gcc-5-cross (Providing standalone cross-toolchain builds) was uploaded/migrated at the same time as cross-toolchain-base

• Support for configurable frontends added to cross-gcc (2015-06-05) (not uploaded yet) http://anonscm.debian.org/cgit/crosstoolchain/cross-gcc.git/log/?h=frontends

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.

Sources

Development occurs at the cross-toolchain Alioth group: http://anonscm.debian.org/cgit/crosstoolchain/

In the debian archive things are arranged like this:

• src:cross-binutils provides the binutils-<triplet> packages. Thin wrapper that builds binutils-source for set of architectures.

• src:cross-gcc-defaults provides gcc-<triplet> (e.g. gcc-arm-linux-gnueabihf) default-version packages. These provide unversioned symlinks to versioned toolchains binaries (e.g. gcc-arm-linux-gnueabihf -> gcc-5-arm-linux-gnueabihf

• src:gcc-4.9 provides the native toolchain packages (for gcc-4.9)
• src:gcc-5 provides the native toolchain packages (for gcc-5)
• src:cross-4.9-gcc-armhf provides the (version 4.9) cross-gcc (and cpp, g++, gfortran) compilers targetting armhf (arm-linux-gnueabihf)

• The various cross-gcc-<ver>-<arch> source packages are generated from a git repo on alioth. This enables us to have one source per target arch so that arches can fail to build independently, but still meaning that there is only one core set of code to maintain.

• src:cross-4.9-gcc-bootstrap-sparc provides (version 4.9) self-contained cross-gcc (and cpp, g++, gfortran) compilers targetting sparc (and other architectures which are not offical debian releases)

• src:gcc-cross-support provides gcc-4.9-for-host and gcc-4.9-for-build packages, which allow packages to depend on native or cross versionned toolchasin

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

i.e

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?

• The actual versioned cross-compiler is in gcc-4.9-arm-linux-gnueabihf
• The package setting which version of the toolchain is currently the default is gcc-arm-linux-gnueabihf
• The package which pulls in a specific version of the target arch cross-compiler is gcc-4.9-for-host:armhf
• The package which pulls in the target arch cross-compiler is gcc-for-host:armhf
• The package which pulls in the build (native) arch compiler is gcc-for-build

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>

e.g.

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 https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results

Appropriate info needs extracting to here