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
Attachment:
signature.asc
Description: Digital signature