Report 3 — Multiarch cross-toolchains

Hi,
Here is my third report on the “Multiarch cross-toolchains” project[0],
mentored by Héctor Orón and co-mentored by Marcin Juszkiewicz.

This time, no really signifant progress, but minor fixes and cleanup to my
gcc-4.7 patches. I've also dropped my modified dpkg package from my repository,
since my changes have been included in dpkg 1.16.5, which means you don't have
to replace any of your installed packages anymore to be able to install the
multi-arch cross-toolchains, as explained in my last blog post[1].

I have started to look at binutils to fix a few (relatively minor) issues with it,
and had a first look at how to discard/avoid building runtime libraries (which
are cross-built packages for the target architecture, and present in the archive
if the architecture exists and doesn't lag behind too much) in gcc-4.7, a task
that promises to be quite painful, as the decision of which libraries/packages
to build is scattered all over the “rules.defs” file. I'll also need to provide
a way for the user to build those packages anyway, in the corner case of a new
architecture or an architecture for which those runtime library packages haven't
been built yet. I'll try to make something clean, though. Beside this one,
there is one last issue with gcc-4.7, #678623, which could prevent C++
cross-compilers to be useful for wheezy. This needs to be thought about and
dealt with as soon as possible.
Then, it should be about it for gcc-4.7 for the time being, and I'll consider
the toolchain as a whole, trying to build cross-toolchains for more architectures
(not only armel and armhf, but things like mipsel, sparc and powerpc too).

Since wheezy is freezing, the focus is not on getting the multiarch cross-toolchains
in the archive, but on providing them in a separate repository (at emdebian,
for instance) while keeping them useful (i.e., getting rid of things like #67823).