Informal multiarch meeting

Date: 26/02/2006

Place: FOSDEM, Brussels

Participants: Tollef Fog Heen, Aurelien Jarno, Guillem Jover, Sven Luther

What is multiarch?

Multiarch gives the ability to install packages from another architecture on a system. It is basically useful for architectures that support 32-bit and 64-bit binaries. It is also useful on architectures which support multiple ABI like mips o32, n32 and n64.

Affected architectures


[1] The host tripplet on n32 and n64 are the same for both ABI, that is mips64-linux-gnu. This is not compatible with the multiarch paths. However it seems mips64-linux-gnuabi32 and mips64-linux-gnuabi64 are supported without any change in config.{guess,sub}.

[2] Sven Luther has concerns with the ppc64 name choosen by the unofficial PowerPC 64-bit port, and there also may have some trademarks issues.

[3] EABI is the new "Embedded" ABI by ARM ltd. EABI is actually a family of ABI's and one of the "subABIs" is GNU EABI, for Linux. The name of the Debian architecture has not be choosen yet.


glibc has already support for multiarch libraries paths. looks for libraries in /lib/$(host triplet) and /usr/lib/$(host triplet), in addition to the standard paths on the architecture. For example that means on i386 the toolchain will look to /lib/x86_64-linux-gnu and /usr/lib/x86_64-linux-gnu.

The libc6 and libc6-dev should also be splitted, in order to make two versions for different architectures to be installable at the same time. That basically means these two packages should only contain libraries.

gcc does not have support for multiarch library paths, however it seems the Ubuntu package has some preliminary support. Basically gcc should look for libraries in the multiarch paths in addition to the standard paths, and also for includes in the multiarch paths.

binutils also does not have support for multiarch paths, but there is a very simple patch in the BTS.

Package management tools

dpkg and apt currently do not support multiarch. They should allow packages from different architectures to be installable at the same time.

First the packages have to support multiarch, meaning that the library package should only contain libraries that have to be installed in the multiarch path to avoid namespace conflicts. Other files, like documentation and changelog should be removed. The proposed solution is to create a -common package to hold those files, and to create symlinks from the library. dpkg has to be smart enough to cope with that. This will increase the number of packages in the archive, but on the other side it will probably reduce the size of the archive by putting more stuff in arch all packages. Some investigations have to be conducted on this side to provide numbers.

dpkg should know that a package is a multiarch package installable on another architecture. The proposed solution is to add a new tag to the control file. Tollef has patches for that. Also as explained before, dpkg has to cope with symlinks pointing to the same location from different multiarch packages for the documentation.

apt is probably the more problematic part. First it has to cope with the increase in the number of packages without taking too much RAM/CPU. Then it has to be able to have multiple architecture in the source.list file and to cope with them.

Starting new ports

Multiarch is only interesting if you have packages from another compatible architecture to install. It is already the case for i386 and amd64, and also for powerpc and powerpc64, but the later port is not official.

This means that new ports have to be started to produce those packages. However, they don't need to be complete ports. Multiarch is only providing a way to install packages from different architectures at the same time. The way to start new ports, the list of packages to support has to be decided by the porter themselves, probably with the ftpmasters and the release team.