[Soc-coordination] Final report — Multiarch cross-toolchains

[Thibaut Girka]

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/
-------------- 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/20120819/fa1401e5/attachment.pgp>