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

Thibaut Girka thib at sitedethib.com
Mon Jun 18 13:36:47 UTC 2012


Hi,

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

During the two last weeks, I've been trying to get my patches to dpkg, apt and
eglibc accepted. The result is that libc6-dev is now M-A: same thanks to Aurélien Jarno (see #666760),
and apt handles arch-specific qualifiers in dependencies (see the changelog[1] for apt 0.9.6),
this isn't the case for dpkg, though, but bug reports (#558095 and #676232) have been filled,
and Guillem should have a look for the next upload.

I've also been working on the toolchain itself, cleaning my patches[2], reducing
differences between natively built runtime libraries (libgcc1, libgomp, etc.)
and cross-built ones, so that one can use such cross-built libs in case those
packages aren't available already (for instance, the architecture is lagging
behind or has yet to be bootstrapped, although in the latter case, there are
other issues as well).

I've basically used cross-arch deps everywhere in the control fields instead
of triplet-suffixed ones, used the same search paths for cross-compilers and
native compilers, hacked around to have packages built for different architectures
with one dpkg-buildpackage call (the cross-tools themselves and the cross-built
runtime libraries), fixed install paths, and suppressed various differences
between cross-compilers/cross-built packages and native ones.

Using the aforementioned patches, one can build a cross-compiler the usual way
(that is, setting “GCC_TARGET” to the Debian arch of their choice,
and regenerating the control file using “debian/rules control”, and rebuilding
the package), and a small set of cross-compiler packages depending on the needed
foreign-arch libs will be built, along with cross-built runtime libraries for
the target, which should not differ much (hopefully, at all) from the natively
built ones, so that they can be installed if the target arch lags behind or
the packages can't be natively built for some reason.

However, those runtime libraries are generally unneeded, and should often be
discarded, as natively-built versions are most likely already in the archive.
Thus, the next step will probably be to only build such packages if explicitly
specified by the user, which would make the build process and the binary package
upload shorter and easier.

My patches break “old-style” cross-compilers packages (as provided by emdebian),
but they shouldn't change a thing to native compilers, even on older systems.
They obviously aren't final, and are subject to change (they are logical patches,
not atomic changesets, and I refresh them in a regular fashion), but I encourage
anyone interested to read them and try them!

Again, patched dpkg as well as cross-compilers are available in my repository[3],
in the “main” and “cross-deps” components respectively. You are of course
welcome to try them!

Thibaut Girka.

[0] http://wiki.debian.org/SummerOfCode2012/Projects#Multiarch_Cross-Toolchains
[1] http://packages.debian.org/changelogs/pool/main/a/apt/apt_0.9.6/changelog
[2] http://emdebian.org/~thibg/patches/gcc-4.7/
[3] 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/20120618/b2df1bb3/attachment.pgp>


More information about the Soc-coordination mailing list