Hi! I have been selected to work on multiarch cross-toolchains as part of the Google summer of Code. Although coding officially started last week, I have been busy with exams and other uni stuff at the time.
Anyway, let's talk about the project itself, that is, multiarch cross-toolchains.
What is multiarch?
In order to understand what the project is about, one need to know what multiarch is. I'll quickly describe it, and I invite anyone interested to read the spec (really, it's interesting, and not that long). Basically, multiarch lets you install binary packages for multiple architectures on one system, and let package managers resolve dependencies as one would expect.
This works by identifying four sets of packages:
Packages that don't need to be aware of multi-arch. Such packages can only be installed for one architecture at a time, and can only be used to resolve dependencies of packages having the same architecture.
Those packages are “Multi-Arch: none” or “multiarch-unaware” packages.
Packages that can be installed for multiple architectures at a time, and can only be used to resolve dependencies of packages having the same architecture.
Those packages are “Multi-Arch: same” packages. They typically are libs.
Packages that can only be installed for one architecture at a time but can satisfy dependencies of any package regardless of its architecture.
Those packages are “Multi-Arch: foreign” packages. They typically are tools working with architecture-independent interfaces. (for instance, gpg, zenity or tar).
Packages that can only be installed for one architecture at a time but can satisfy any dependency annotated with “:any”, regardless of the architecture.
Those packages are “Multi-Arch: allowed” packages. They are packages providing both arch-dependent and arch-independent interfaces. They are typically things like python, which can be used to interpret arch-indep files, but providing arch-dependent interfaces for C extensions.
Anyway, multiarch is an amazing thing that may be of use in various cases, such as running i386-only software on an amd64 system, running armel software on an armhf system, running i386 software on an armhf system using qemu-user-static and binfmt, cross-grading (switching, for instance, from i386 to amd64 on a running system), and, in our case, easing cross-compilation.
State of cross-toolchains in Debian
There aren't really cross-toolchains available in Debian (although some can be built from source packages), but they are available in emdebian's repositories.
However, those packages predate multiarch, and don't make use of it. Instead, they depend on special packages converted using dpkg-cross. Such packages are merely arch: all versions of foreign packages, with files moved to arch-qualified paths to prevent conflicts with “normal” packages.
Such packages thus have to be generated from real packages, either manually or using some sort of automation. In addition, this additional step brings several issues, like keeping in sync converted packages with real packages from the archive.
With multiarch, such packages are rendered useless, and may in fact bring additional problems, since “converted” and multiarch packages may share the same files, and thus may not be co-installable.
Switching from dpkg-cross to cross-arch deps
Cross-toolchains packages currently depend on a few packages converted using dpkg-cross (ex: libc6-$ARCH-cross and libc6-dev-$ARCH-cross for some packages). They need to depend on the “real” package with the right arch (ex: libc6:$ARCH, libc6-dev:$ARCH).
The obvious way to do so is by annotating the dependency with a specific arch qualifier (ex: “Depends: libc6:armhf”). This is, however, not covered by the multiarch spec.
Note that some “lib*-$ARCH-cross” packages will remain (for instance, libgcc1-armhf-cross).
Indeed, those packages are different from the packages mentioned above in that
they are of the architecture of the build system and actually part of the toolchain itself.
The above isn't actually true. Indeed, those packages are runtime library cross-built during gcc's build.
Likewise, cross-toolchains may build-depend on foreign packages (ex: libc6-dev). Thus, specific arch qualifiers must be handled in the “Build-Depends” source package field too.
Changing dpkg and apt to support that should be fairly straightforward. In fact, I already have a few patches, but I need to refresh them, maybe clean them up a little, and push them a little harder to get them accepted!