Differences between revisions 10 and 11
Revision 10 as of 2014-11-07 18:47:19
Size: 12151
Editor: wookey
Comment:
Revision 11 as of 2014-11-07 18:50:13
Size: 12298
Editor: wookey
Comment: fix broken links. Inclde info on crosstoolchains repo
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
Everything that works is available for jessie and unstable at Everything that works is available for jessie and unstable in the [[https://people.debian.org/~wookey/tools/debian/|Debian Cross-toolchains]] repo.
Line 23: Line 23:
 Other packages are available from the Debian Crosstoolchain repository. See 'Installation' below.  Other packages are available from the [[https://people.debian.org/~wookey/tools/debian/|Debian Cross-toolchains]] repository. See 'Installation' below.
Line 52: Line 52:
These packages did not quite get into Jessie so you need to install them from [[https://people.debian.org/~wookey/tools/debian/|the Debian Toolchains]] repository. Create {{{/etc/apt/sources.list.d/debian-crossstools.list}}} containing: These packages did not quite get into Jessie so you need to install them from [[https://people.debian.org/~wookey/tools/debian/|the Debian Cross-toolchains]] repository. Create {{{/etc/apt/sources.list.d/debian-crossstools.list}}} containing:

CrossToolchains

This is in flux

This document describes plans for cross-toolchains in Debian. Some of this is now in unstable, but exactly what (if anything) will end up in Jessie is currently (end October 2014) unclear.

Some (cross-binutils, cross-gcc, cross-gcc-defaults) but not all (pkg-config, crossbuild-essential) of that is now in unstable.

Everything that works is available for jessie and unstable in the Debian Cross-toolchains repo.


Status of cross-toolchains in the Debian archive

In jessie/testing

  • cross-binutils (targetting arm64, armel, armhf, amd64,, i386, mips, mipsel, powerpc, ppc64el)

    Other packages are available from the Debian Cross-toolchains repository. See 'Installation' below.

In unstable

  • cross-binutils
  • cross-gcc packages built from gcc-4.9 only for amd64, targetting the linux architectures supported in Debian: armel, armhf, arm64, mips, mipsel, powerpc, ppc64el gcc, g++ and gfortran cross-compilers are provided
  • cross-gcc-defaults metapackages which provide symlinks to the current version of the compilers (so that 'arm-linux-gnueabi-gcc' works when the compiler binary is actually arm-linux-gnueabi-gcc-4.9

In experimental

  • crossbuild-essential metapackage to pull in gcc, g++, libc-dev:arch and dpkg-cross (for autoconf and cmake cache/toolchain file support)

Installation

For jessie/testing

Cross-toolchains for jessie are available, but only cross-binutils is in the main archive. Other packages come from an external repository.

The toolchains install on amd64 machines, targeting these architectures:

  • arm64
  • armel
  • armhf
  • mips
  • mipsel
  • powerpc
  • ppc64el

These packages did not quite get into Jessie so you need to install them from the Debian Cross-toolchains repository. Create /etc/apt/sources.list.d/debian-crossstools.list containing:

deb https://people.debian.org/~wookey/tools/debian/ jessie main
deb-src https://people.debian.org/~wookey/tools/debian/ jessie main

people.debian.org is only available over https so you need to make sure that apt-transport-https is installed.

You will also need the archive key

build-essential-<arch> packages exist to aid in installing the correct cross-packages. For instance to install the armhf cross-toolchain, first enable the foreign architecture, then install build-essential-armhf :

sudo dpkg --add-architecture armhf
sudo apt-get update
sudo apt-get install crossbuild-essential-armhf

This will pull in the required packages to cross-build for the target architecture, namely libc6-<arch>, gcc-<triplet>, g++-<triplet> and dpkg-cross.

For unstable

You must enable the appropriate (HOST) foreign architecture before installing the cross-compiler.

dpkg --add-architecture armhf
apt-get update

It is recommended to install the cross environment like this as that pulls in all the necessary components:

apt-get install crossbuild-essential-<arch>

i.e

apt-get install crossbuild-essential-armhf

But you can install just the compiler with

apt-get install gcc-arm-linux-gnueabihf

Note that gcc-arm-linux-gnueabihf is (like the native 'gcc') just a metapackage, which brings int he current version of the actual compiler gcc-4.9-arm-linux-gnueabihf (c.f. gcc-4.9)

g++-<triplet>, and gfortran-<triplet> packages also exist.

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 jessie+1 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 need extracting to here

Cross-toolchain building

There are various parts to the cross-toolchains, wich come from several source packages. The cross-gcc packages themselves can be built in two different ways.

  1. Multiarch gcc builds
  2. Bootstrap cross-toolchain builds

The differences are explained on ?MultiarchCrossTroolchainBuilds.

The former builds (for example) gcc-arm-linux-gnueabihf (and cpp,g++,gfortran) against the linux-libc-dev:armhf, libc6-dev:armhf, libstdc++-dev:armhf and libgcc1:armhf already in the archive. The build is quick and simple, but the resulting package has cross-arch dependencies (on the various :armhf packages), so you need to enabled multiarch to install them. You will need to enable multiarch for most cross-builds anyway

The latter builds (for example) linux-libc-dev-cross-armhf, libc-dev-cross-armhf, libstdc++-dev-cross-armhf, libgcc1-cross-armhf and gcc-arm-linux-gnueabihf (and cpp,g++,gfortran) from the kernel, glibc, and gcc sources, via the toolchain bootstrap process. Because the foreign-arch libraries are converted to build-arch packages, the toolchain does not need multiarch enabled to build, but the build is much longer and more complicated, and you end up with two copies of those libraries on your system.

This type of build is necessary when the target architecture is not in the debian archive as the libraries are not available to build against.

Sources

In the archive things are arranged like this:

  • src:cross-binutils provides the binutils-<triplet> packages

  • src:gcc-cross-support provides the gcc-4.9-for-host and gcc-4.9-for-build packages

  • src:cross-gcc-defaults provides the gcc-arm-linux-gnueabihf and gcc-for-host default-version packages.

  • src:gcc-4.9 provides the native toolchain packages
  • src:cross-4.9-gcc-armhf provides the (version 4.9) cross-gcc (and cpp, g++, gfortran) compilers targetting armhf (arm-linux-gnueabihf)
  • 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)
  • The various cross-gcc-<ver>-<arch> source packages are generated from a http://anonscm.debian.org/cgit/crosstoolchain/cross-gcc.git|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.

The missing sources (cross-gcc-bootstrap, gcc-cross-support, cross-support) repos will be uploaded there shortly so that everything is in one place for maintenance.

Multiarch vs Multilib

Targetting related architectures (such as i386/amd64, armel/armhf, mips/mipsel) can be done in two different ways. You can either build one cross-compiler for each target, and install whichever ones you need, or you can build one cross-compiler which has two or more multilibs installed, install just that one cross-compiler and use build options to control which code is output.

i.e on amd64 you can target i386 either by running i386-linux-gnu-gcc, or by running x86_64-linux-gnu-gcc -m32

These options are not consistent across different architecture sets, whilst use of <triplet>-gcc always works:

  • arm-linux-gnueabi-gcc produces the same (armel) output on all arches arm-linux-gnueabihf-gcc -mabi=softfp can be used instead on armhf to produce armel binaries.

Building these multilibbed cross-toolchains is are a lot more fiddly than plain multiarch ones. Thus the current debian cross-toolchains are not multilibbed and only support the <triplet>-gcc method. Install whichever targets you need, and use the same commands everywhere. Encourage upstreams to call tools this way, rather than using -mabi=blah options, although in x86 world the use of m32/m64 is rife and is probably too late to change. Some packages may need their build options adjusting to do this right.