Hi, First, the “3-5 lines summary” (sorry, 6 lines): I've patched dpkg and apt to handle cross-arch (build-)dependencies, fixed the handling of “:any” and “:native” qualifiers in build-dependencies, and helped multiarching libc*-dev. All those changes have landed in wheezy. I have also modified gcc-4.7's packaging to switch from “dpkg-cross style” dependencies to cross-arch deps, use multiarch paths and split development files out of gcc-4.7 to some libgcc-4.7-dev package. And then, the final report: Since the last report, I have rebased and fixed my patch about splitting header and lib files out of the gcc-4.7 package to libgcc-4.7-dev. It won't be useful for wheezy, but I plan to get it into jessie some time after the GSoC. I've also tried other target architectures and multilib, the result is that multilib doesn't play well with multiarch. At all. Indeed, multilib relies on a symbolic from /usr/include/asm to /usr/include/$triplet/asm, which conflicts with multiarch. Furthermore, gcc's installation process tries to guess where to install libs, by testing the existence of a /usr/lib32 directory. This means that building depends on what's installed where on the build system, and might result in misplaced files (and thus FTBFs) when cross-building for a 32-bit system (with multilib enabled) from a 64-bit system. Even worse, natively building can fail in very specific circumstances, even though the build-dependencies are installed. Those issues could be resolved for jessie, but that would involve multilib compilers depending on libc6-dev:$foreign instead of libc6-dev-$foreign, and one could wonder what would be the benefits of multilib compilers over multiarch cross-compilers there... So, we've decided to not care about multilib for the time being. Hence, building cross-compilers should be done with the DEB_CROSS_NO_BIARCH flag set. I've also fixed an issue regarding building for some architectures (including powerpc, for which cross-compilers now build fine) on multiarch-enabled environments. I took a look at binutils, which installs things in strange places when building a cross-binutils package. Indeed, it installs some header and lib files in /usr/$host_triplet/$target_triplet/{include,lib}/. It is not really an issue since only binutils itself cares about those files. At first, it seems odd to qualify those files for both the host and target systems. However, they are target-specific libs for the host arch, so, that's probably fine, although, to be consistent with the multiarch spec, the paths should probably be along the lines of /usr/{include,lib}/$host_triplet/$target_triplet/. The same kind of files are provided by binutils-dev, in which the target and host systems are the same. This package is M-A: None, and the files aren't arch-qualified at all. It would make sense to qualify them like regular libs and make binutils-dev M-A: same, which would be useful to cross-compile a few things (24 packages in Debian, including llvm and ksplice). I have given thought about how cross-compilers could be built automatically, but I haven't found out a good way to do that yet. It is impossible to build multiarch cross-toolchains as part of the normal build of gcc, since src:gcc-4.7 would then require libgcc1:$host and (libgcc1:$target for each $target in the targets list) to be of the same version. However, if one target succeeds in building gcc-4.7 before the host starts, it would be stuck forever, as the only way of having libgcc1:$host to be the same version as the others would be to build gcc-4.7, which is impossible because libgcc1:$host is of a lower version... Another solution would be to have another source package, responsible for building cross-compilers from gcc's source package. As far as I know, that's how it is done for ubuntu, but apt-get sourcing gcc-4.7 from a source package feels wrong to me... Then, I thought about it in a different way: building cross-compilers is like building the same software with a different feature set, a different purpose. That sounds a lot like the “Build-Profiles” proposed[0] to bootstrap toolchains, except, in this case, profile-using uploads have to be accepted and tracked separately, like different packages. Not sure if it's a good idea, but Build-Profiles are going to need some discussion anyway! In the end, while multiarch cross-compilers are functional, there are still a few shortcomings: cross-g++ can be built, but not installed in wheezy, they are not suited for the archive, as they are not buildable in a fully automated fashion (one still have to set GCC_TARGET and regenerate the control files), and cross-built runtime libs (unneeded, as already present in the archive) are still built and included in the changes file (although one can easily strip them before uploading by running something like “grep -v ${GCC_TARGET}.deb”. You can find powerpc, arm and armel cross-compilers for i386 and amd64 at the usual place[1]. I have unsuccessfully tried to build a mips cross-compiler, but the fix should be straightforward, I'll look into that soon after the GSoC. Beware, though, because they share the same ld.so path, you cannot co-install any combination of the following archs (that's not specific to cross-compiling, but more a multiarch issue): s390 powerpc mipsel mips hppa. Regards, Thibaut Girka. [0]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661538#131 [1]: http://emdebian.org/~thibg/repo/
Attachment:
signature.asc
Description: Digital signature