FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 23, 2012 12:34 UTC (Thu) by wookey (guest, #5501)
In reply to: FOSDEM: Multiarch on Debian and Ubuntu by aleXXX
Parent article: FOSDEM: Multiarch on Debian and Ubuntu

[Hey, wow, I'm in LWN! :-) ]

The slides are here: http://wookware.org/talks/ (the ELC version given 10 days later has marginally improved slides)

Multiarch does make crossbuilding (on Debian/Ubuntu) much easier in several ways. I cover this in the talk, but to save you watch me blither for 40 mins I'll write it down here.

1) Cross-dependencies.
There has been no proper solution to this in Debian to date, The closest were xapt (which simply installed every dependency in the system twice, once for BUILD arch and once for HOST arch), and xdeb which has a big list of heuristics for package-names that should be cross-installed and library packages which aren't named lib-something, etc). Both of these are pretty cranky, an the huge pile of dpkg-crossed 'local' packages caused upgradeability problems too.

Because multiarch specifies whether things are co-installable (and only satisfy dependencies within an architecture) - (i.e are like libraries) or whether they are not co-installable, and satisfy deps across arches (i.e are like tools), this info provides a very good mapping to whether to install a BUILD arch of HOST arch version of a build-dependency, and there is a syntax to express the exceptions. So suddenly cross-build-deps is a properly defined, deterministic thing that just falls out of the packaging and tools.
apt-get -a<arch> build-dep <package> should install the build tool packages, and cross-library/header packages for the build.

2) Libraries and headers now have a canonical path that doesn't change between build time, run time and install time. Because of this the whole cmake/autoconf/libtool/--libdir shenanigins gets a lots simpler. Files have a path - use it. architecture dependent files have an architecture qualified path. It's beatiful in comparison to what went before.

3) Its easy to install runtimes of a different arch in the system (and their dependencies) and thus (if you have CPU or emulation support) expect them to run, so wrong-arch scripts run at build-time can just work, or you can do your builds as fake-native where a lot of the tools have been replaced by BUILD arch ones. None of this is new (see scratchbox, scratchbox2, OBS), but it all gets a whole lot more orthogonal, which ought to make it a lot easier to use and maintain. Using multiarch for OBS or scratchbox-style not-really-cross building is currently pretty-much untested, so this is my enthusiasm showing through to some degree, but I don't see why it won't work.

Yes, I agree, packages still need to be constructed properly so that can cross correctly, and preferably without running any wrong-arch binaries (The case where you simply don't _have_ qemu support for the HOST arch, so all qemu bodging is cheating, is still very important), but the whole multiarch co-installation infrastructure and canonical pathnames gives us a lot more than just less hassle from RPATH (Debian removes RPATH in almost all cases anyway becauase it's wrong and bad for almost everything except plugins)

I've set up a multiarch cross buildd in order to track the current state of play in terms of what actually works (not a huge amount right now, but I expect that to improve quite rapdily) here:
http://people.linaro.org/~wookey/buildd/

to post comments

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 23, 2012 19:31 UTC (Thu) by aleXXX (subscriber, #2742) [Link] (2 responses)

Ah, ok. Section 1) is the distro POV of cross compiling. That's a good thing.
And there are really no problems with overlapping files (headers) ?

What do you mean with "Files have a path - use it" ?

Regarding 3) I'm really not up-to-date with that.
The last time I used scratchbox, I had to actually log in to it to do something. Has this changed ?

Alex

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 24, 2012 9:11 UTC (Fri) by rvfh (guest, #31018) [Link]

> And there are really no problems with overlapping files (headers) ?

I think headers should be common, and kept in /usr/include. If a header has arch-specific sections it should be easy to fix with correct #defines.

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 28, 2012 18:10 UTC (Tue) by pboddie (guest, #50784) [Link]

What do you mean with "Files have a path - use it" ?

I imagine he means that files you're building and installing go in a location that won't differ from the deployed location on a foreign system. So whereas you'd previously have to make foreign libraries targeted for /usr/lib but which can't be installed there because your host's libraries already reside there - problematic if your tools expect those foreign libraries to be there when building other things which depend on those libraries - you can now give the tools a canonical path for each architecture and the host and foreign libraries won't conflict with each other.