Contents
Related Pages
CoinstallableToolchains : Scheme to allow co-installable compilers
MultiarchCrossToolchainBuild : Info on building toolchains using multiarch methods
toolchain/BootstrapIssues : Breakage found when building debian crosstoolchains (might save you some time!)
Cross toolchain
Identify issues
- There are currently different approaches for cross toolchain builds:
- Cross packages output of former Debian source packages
- Not good idea, because builds would take long and a cross build failure would hold native builds which it is not really good idea.
- If cross packages are built off former Debian packages a version skew is introduced.
Build $build_host_arch ('amd64') -> any on one source package
- Not good idea, as an architecture build failure holds the rest of architectures, i.e. build can take 48h and imagine situation when 10th arch fails...
- Build $build_target_arch ('armel') complete run from one source package
- That is not Debian approach but making modular builds, but simplifies build process
- we can upload 11 source packages at once and if some of them fail then we have some others built anyway - less work on fixing
- Build $build_target_arch ('armel') complete run from multiple source packages
- Modular builds are nice, but it is a burden to maintain multiple source packages per each $build_target_arch
- Jonas proposes to build current dpkg-cross packages as packages architecture 'all' built on one specific architecture, i.e. linux-libc-dev-armel-cross can be built on armel as arch:all package.
- This approach avoids bootstraps (saving compile time), keeps package maintainership in the proper Debian source packages, but makes it difficult to build cross compilers for new architectures.
?NumSourcePackages = ($build_host_arch ('amd64') -> $build_target_arch ('armel') ) x (11 ports + X non-official ports) If we split the build in several source packages then that means we need to maintain more source package burden:
Y source packages x ?NumSourcePackages
- A possible optimization at build time would be to have cross compilers to build depend on themselves.
- Building cross gcc requires libc(-dev) and linux-libc-dev packages from target arch - for now they need to be fetched by hand which is impossible on buildd or we can bootstrap them from sources, but that it is not currently implemented in Debian packages (Linaro/Ubuntu packages do implement that), there is work in progress.
Source
- Marcin's work on cross toolchain packages for Ubuntu and Debian:
http://git.linaro.org/gitweb?p=people/hrw/cross-toolchain-packaging.git;a=summary
- git://git.linaro.org/people/hrw/cross-toolchain-packaging.git
- There is an open question of which $build_host_arch do we support, at the moment, amd64|i386 are built, powerpc could also be built.
Handling cross compiler versions/defaults
For now cross gcc uses update-alternatives to select default version. Since my (Marcin) changes landed in gcc-4.[45] versions (also in gcc-4.6 now) the newest version is selected by default. This affects Debian where 4.4 is default and 4.5 can be provided. In Ubuntu it is solved by 'gcc-defaults-armel-cross' package.
Marcin notes
Status
Currently we have two ways of doing cross toolchain in Debian/Ubuntu world:
EmDebian one (echo $arch >debian/target + build)
- Ubuntu one (bootstrap whole cross compiler)
EmDebian way
Should work in any Debian derived distribution due to simpleness of it. The problem is that it is manual process which can be automated but is still impossible to do on buildd - and as such it can not be added into Debian repository. EmDebian developers solved that by having daemon which rebuilds toolchain packages after their updates in Debian archive.
Another problem is manual fetching of eglibc and linux packages fortarget arch. But this part can be solved by using multiarch capable APT (apt-get -o APT::architecture=armel download libc6-dev).
Ubuntu way
Ubuntu way handles building of cross toolchain in other way - by fullbootstrap of it. Due to fact that final gcc (gcc stage3 in bootstrap terminology) requires target headers to be available in /usr/$ARCH/ directories I split toolchain into two packages:
- armel-cross-toolchain-base (does binutils, eglibc, libgcc)
- gcc-4.x-armel-cross (does gcc without libgcc packages)
So far packages for gcc 4.4 and 4.5 are created. 4.6 version will follow soon - it will be basically copy of 4.5 one.
But how to get Ubuntu source packages working under Debian?
Experimental requirements
First we need binutils 2.21 and gcc-4.5 from experimental - they contain all my changes which I did for Ubuntu 10.10 'maverick' and all later ones. Many things got cleaned, code duplication which was present for cross targets got eliminated in favour of reusing native packaging as much as possible. Effect is that we have -dbg packages for all libraries and soon also -dbgsym ones. Some work may still need to be done to make sure that cross toolchain for all of Debian architectures can be built and used.
In-progress packaging
Next requirements are armel-cross-toolchain-base and gcc-4.5-armel-cross from my git repository at git.linaro.org server. Latter one is same as Ubuntu one but has build dependencies lowered (Ubuntu has eglibc 2.12, Debian has 2.11 for example). Worse situation is with armel-cross-toolchain-base one...
How it works
To bootstrap cross toolchain I reuse sources which are available in *-source binary packages for binutils/eglibc/gcc-4.5/linux-2.6 components. For binutils and gcc-4.[456] there is no problem as changes are present.
Eglibc/Linux problems
Worse situation is with eglibc and linux-2.6 -source packages as they do not provide Debian packaging inside. I opened bug against linux-2.6 but so far it got refused with answer like "wait for multiarch it will solve your problem". I assume similar answer will be for eglibc but I will report wishlist bug anyway. So far as a work around I included whole eglibc packaging (4MB) inside of armel-cross-toolchain-base and same with linux-2.6. Effect is ugly, non-maintainable but at least I have something to test.
Build problems
Current Debian builds of final eglibc fails on building "nscd/others". It is linking problem as ld is not able to find ld-linux.so for some symbols. It links fine if I call failing line with library added.
If build fails on "build-linux" stage then it is a reason of not whole linux-2.6 packaging copy but it was solved by making it complete.
Bootstrap order and dependencies
1. binutils-cross sysrooted 2. gcc1-cross (requires 1) 3. linux-headers-cross 4. eglibc1-cross (requires 2) 5. gcc2-cross (requires 4, gives libgcc packages) 6. eglibc-final-cross (requires 5, gives all eglibc packages) 7. binutils-cross without sysroot (gives binutils-cross packages)
Why two builds of binutils? gcc1 and gcc2 are build with sysroot enabled as we do not have access to /usr/ARCH directories during build. So we need binutils which will also use sysroot.
Patches used
- Solves missing file in -source package - I should fix binutils for not needing this as we apply it again (it is normally applied during normal binutils builds due to missing file in upstream tarball of 2.21 release).
- patches/binutils/add-gnu-oids.texi.diff
- Disables building of documentation, sources, udebs as we do not need them. Need to clean them or change to shell action.
- patches/eglibc: 0001-limit-packages-for-backport-version.patch local-no-notneeded-packages.patch debian-local-no-notneeded-packages.patch
- Disable building of localedata for all languages except first one. The process of building them takes lot of time and we do not use this data in cross toolchain.
- local-kill-locales.patch debian-local-kill-locales.patch
- Debian does not ship eglibc manual in eglibc-source but also does not ship manual/ directory which was created by one of debian patches. This patch handles this. Need to report bug.
- debian-local-remove-manual.diff
- Force using of gcc-4.4 to build eglibc under Lucid. Was used only for Linaro toolchain PPA and got dropped on Friday (solved by applying it into eglibc). Need to merge ubuntu/natty version into debian branch.
- lucid-force-gcc-4.4.patch
- Do not apply patches when PATCHED_SOURCE=yes is given. Added to Ubuntu eglibc some time ago on my request.
- ubuntu-backport-50-patched-sources.patch
- Stages support for bootstrapping cross compiler. Taken from Ubuntu packaging.
- ubuntu-backport-51-stages.patch
- Moves GFDL_INVARIANT_FREE variable outside of stages support so it got used under Debian. Need to report bug and get it merged.
- patches/gcc-4.5: handle-doc-for-stages.diff
- Do not use gold to build compiler - it fails on building because there is no lto plugin built during gcc2 stage. Merge request sent long time ago, need to check it again and discuss with Matthias Klose.
- no-gold.diff
- Adds support for building linux-libc-dev package only.
- patches/linux: linux-stage1.diff
Multiarch future
There is ongoing work on having multiarch dpkg working for both Debian and Ubuntu distributions. When it will get to final state both ways of building cross compiler will have to be changed because there will be no need to manually fetch target arch packages because we could just build-depend on them. But thats future - first stage of deploying multiarch will not give us this because whole build infrastructure of both distributions needs to be changed first.
But what we will have to do when we will have final multiarch support? I think that there will be will be able to abandon armel-cross-toolchain-base package in favour of binutils-cross one as there will be no need to cross build eglibc or linux headers (we will just build-depend on target packages).
On Ubuntu side I will still maintain (then deprecated) packages due to LTS support which I promised to our users. But this part will not affect Ubuntu 'current' or Debian 'wheezy'.
Results
Common development on cross toolchains will happen in a Cross Toolchain Team at Alioth under collab-maint