Cross Building in Debian Terminology: BUILD= machine stuff is built on HOST= machine stuff will run on TARGET= machine code is generated for normal native compiler is BUILD=HOST=TARGET cross-compiler is BUILD=HOST!=TARGET cross-building native compiler: BUILD!=HOST=TARGET tools which have arch-specific behaviour prefixed with -gcc -gcc-4.7 -pkgconfig -g-ir-scanner packages installed for particular arch: packagename:arch crossbuild-essential- empty package depending on gcc- g++- pkg-config- libc6-dev: dpkg supports :any, :native, : in stable so packages can be uploaded so apt-get build-dep -aarmhf pango just works. NOTE: sbuild/wanna-build almost supports this but not quite, so Build-Depends: foo:any doesn't work yet It doesn't support build-profiles. Patches are available. so apt-get -oAPT::Build-Profile=stage1,cross build-dep -aarmhf pango needs those patches: http://people.debian.org/~wookey/bootstrap/patches/profiles/tools/ Agenda: * Cross compilers - current situation - armhf, armel, mips, mipsel, sparc, ia64, i386, powerpc cross compilers at emdebian.org but not well-maintained so currently uninstallable - armhf, armel, arm64, powerpc cross-compilers in Ubuntu - crossbuild-essential packages in ubuntu and my bootstrap repo - awaiting toolchains * Built in different ways emdebian: gets libc:HOST from HOST arch, uses dpkg-cross to convert. Built with buildcross (in experimental) ubuntu: 7-step bootstrap using linux-source, eglibc-source, binutils-source, gcc-source Source package per-arch: -cross-toolchain-base Builds binutils-, gcc-4.7-, -pkgconfig, gcc-cross-defaults, linux-libc-dev--cross, libc6-dev--cross, libstdc++--cross * Building the crosstoolchain using multiarch gcc4.7 and gcc4.8 both support building with multiarch against HOST-arch libs (libc6, libgcc1, libstdc++), but that needs multiarch enabled on the buildds. "with_deps_on_target_arch_pkgs=yes" described at: https://wiki.debian.org/MultiarchCrossToolchainBuild Binutils is dead simple: TARGET=armel dpkg-buildpackage -b gcc needs: apt-get install libc6-dev:armel libstdc++-4.8-dev:armel DEB_TARGET_ARCH=armel DEB_CROSS_NO_BIARCH=yes with_deps_on_target_arch_pkgs=yes dpkg-buildpackage -b Much quicker and simpler. Builds gcc once, not 3 times, and doesn't build eglibc twice, nor kernel I propose we should aim for: - binutils-cross source package that builds binutils-cross for all supported arches - gcc-cross- source package that builds gcc-, one per arch (and gcc-defaults) - build-essential source package that builds all arches crossbuild-essential - pkg-config source package that builds all arches triplet-pkg-config (just symlinks) This is no use for toolchains where debian arch does not yet exist (e.g. arm64). New arches still need the full bootstrap process. Would be nice to develop source dependencies so we can drop all the foo-source packages and depend on foo:source. Not worth delaying over. Is this in fact really easy? (apt-get install foo:source downloads to /usr/src?) * Mingw as multiarch partial arch * ARCHxARCHxARCH build matrix - which ones should we support? - amd64 -> everything? - i386 -> everything? - arm64 -> everything? - armhf -> ? - armel -> ? * Co-installable HOST->TARGET toolchains - share scheme with cross toolchains - See bug (or details below) * Bare metal toolchains * Raspbian people would really like 'compiler-defaults' package to build all compiler source package against so they don't have to change gcc-4.4, gcc-4.6, gcc-4.7, gcc-4.8, gcj-*, gdc-*, fpc, gnat-* on every upload. [cjwatson: deleted ghc, this works completely differently and the whole Haskell system has to match it] - Is that possible? * Tradeoffs to consider - multilib vs multiarch (multilib on x86 is entrenched, not yet on arm. Mips?). Often you can use multiarch or multilib to do the same thing (have different abi libs available) Do both everywhere? favour multiarch? - Bootstrapping vs normal builds Bootstrapping new arch always needs multi-stage bootstrap build of linux-libc-dev, binutils, gcc, eglibc, gcc, eglibc, gcc. Once arch is established this is not normally needed. * distro builds vs 'upstream stuff' - multiarch makes it really easy to use system libraries. quite hard to use other versions (due to multiarch sync). - Good for distro building and backports. less good for upstream development. * Request has gone in for 'debian-cross' mailing list - bugs.debian.org/717332 currently 'pending'. * Issue with translatable dependencies. Packages which build-dep on 'gcc-' or binutils What gcc- actually means is: probably 'HOST_ARCH-c-compiler-4.7', but maybe 'BUILD_ARCH-c-compiler-4.7', or both. Can't just fix build-dep as the packagename depends what you are building for: -a armhf -> arm-linux-gnueabihf-gcc-4.7 -a mips -> mips-linux-gnu-gcc-4.7 and just depending on 'c-compiler-4.7' and replying on multiarch won't work as that will get you gcc-4.7:armhf instead of arm-linux-gnueabihf:amd64 which is no use. (This is about target arch, not host arch). http://bugs.debian.org/695287 2 possible mechanisms to fix this: 1) A short list of which packages have this property of translatability: gcc, binutils, pkgconfig, g++ etc. Putting these in sbuild works as a hack. Better is to put Cross-name: Yes into each of these binaries, meaning 'when building for HOST_ARCH != BUILD_ARCH, this build-dep should have -package used instead build-dep line looks like: gcc-4.7 [cross], gcc-4.7 2) Add a new substvar: Build-Depends: gcc-4.7-${host:Gnu-Type} [profile.cross], gcc-4.7 [!profile.cross] In the meantime, cross-build-essential glosses over most of this issue, except for things which specify a particular gcc version. * build-deps on binutils-dev This needs fixing. binutils-dev is not MA:same and the maintainer does not want to make it so. What this actually means is that things want libiberty-dev for something. This has no fixed api so must always be included statically, but still needs splitting out of binutils to provide this. gcc has a (different version too) * co-installable compilers Currently we can install gcc-ver and gcc-ver-triplet but you can't install gcc:i386 and gcc:amd64 This is useful (e.g because ghc depends on gcc and wanting to install ghc:i386 or ghc:x32 to use less RAM makes a lot of sense). Not a high priority, but is useful and removes arbitrary distinction between compiler and cross-compiler. Makes things nice and orthogonal. gcc-ver is MA:none and cannot simply be made MA:foreign ghc:i386 needs gcc(core):i386 but leaving gcc(core):amd64 installed native compiler is BUILD=HOST=TARGET cross-compiler is BUILD=HOST!=TARGET so instead we have gcc--x86_64-linux-gnu gcc--i386-linux-gnu gcc--arm-linux-gnueabihf etc user installs gcc-ver (arch:any) which is now just symlinks to gcc-ver-triplet with TARGET=HOST. so gcc-ver-TARGET:BUILD ('actual compilers' packages) are MA:foreign gcc-ver:BUILD is MA:none, arch:any, depends on gcc-ver-BUILD so we should be able to install gcc-ver-TARGET:BUILD (cross) gcc-ver-BUILD:BUILD (native) g++-ver-TARGET:BUILD (cross) g++-ver-BUILD:BUILD (native) gcc-4.8-arm-linux-gnueabihf:armhf built from 'gcc-4.8' source. this lives in armhf architecture of repo gcc-4.8-arm-linux-gnueabihf:amd64 built from 'gcc-4.8-cross' source. crosscompiler for armhf on amd64 this lives in amd64 architecture of repo