[Soc-coordination] Report 3 — Multiarch cross-toolchains

[Thibaut Girka]

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


First, I have to admit I've been slacking a bit since the midterm evaluation.
I'm a bit late according to my original planning, as I should be in the middle
of figuring out what changes to wanna-build, buildd, sbuild, britney and such
are needed to support cross-arch deps in the archive, as well as working on a
way to automate building cross-compilers so it can get in the archive.


However, there has been a slight change in the planning: indeed, during
Debconf, the issue of libstdc++6-4.7-dev depending on g++-4.7 (#678623) was
discussed[1], and the proposed solution was to split gcc-4.7 in two packages,
and likewise for the other compilers such as gfortran or gobjc.
I've started to work on this, and I have a first patch waiting for reviews.
However, such a change would introduce file conflicts between the “old”
gcc-4.7/gcc-4.7-multilib packages and the new lib*gcc1-*-dev ones, meaning that
those packages must conflict with older versions of gcc-4.7/gcc-4.7-multilib.
Unlike my previous patches, it's useless and actually harmful to provide
third-party packages implementing this change until it gets in Debian.


I've also built amd64 (target) single-lib and multilib cross-compilers for i386.
While it may seem useless (gcc-multilib for i386 just does the same), it enabled
me to spot and fix a few errors I've made in an earlier patch, as well as a few
other issues that may affect many other arches too.
This means that things like sparc→i386 or sparc→amd64 cross-compilers (which
are things I've seen requests for a couple of time) should now build and work
properly, although I have no sparc hardware to confirm!
I plan on trying other arches (mips, mipsel, powerpc, sparc...) in the following days.


The issue of not building foreign packages (which are, unless working on a new arch,
cross-built versions of things already in the archive) when building a cross-compiler
still remains, as I still need to figure out a clean way to do it. If possible,
I would like to avoid building those libraries, not only the binary packages.


Likewise, the issue of automating the build process hasn't been resolved.
I'm contemplating the idea of making cross-compilers part of the normal
gcc build, but that's maybe not a great idea, since it would involve
a great deal of changes in gcc's packaging, it would significantly
increase build time (however, slower arches wouldn't provide many, if any
cross-compilers, so, only faster arches would be impacted, somehow limiting
the lag of slower arches), and mean any “supported” cross-compiler FTBFS
would mean a gcc FTBFS, which may or may not be a good thing.


So, to sum up the state of the project:
* Multi-arch cross-toolchains binaries can already be provided by a third-party
  for use on a Wheezy system for various arches (at least i386, amd64, armel
  and armhf), minus the C++ issue (#678623).

* However, it would involve some additional scripting/manual intervention
  to prevent cross-built libs to be uploaded. This can be fixed before the end
  of the GSoC, and it hopefully will be.

* Even with the aforementionned issue resolved, those cross-toolchains can't,
  for various reasons, be built and managed by the software running the archive.
  This might not be fixed before the end of the GSoC (and it's too late for Wheezy
  anyway, so, that's not a priority).


Thibaut Girka.

[0]: http://wiki.debian.org/SummerOfCode2012/Projects#Multiarch_Cross-Toolchains
[1]: http://wiki.debian.org/ToolChain/Cross/DebConf12
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20120730/16e9f221/attachment-0001.pgp>