Translate

Archives

Multiarch

Multiarch is a general solution for installing libraries of more than one architecture on a system. It was first proposed in 2004. It solves the problem which was created when Linux distributions standardized on the /lib and /lib64 directories for libaries.

The core concept is to put libraries for each architecture into architecture-specif ic paths. For example,

  • /usr/lib/libfoo (amd64) —> /usr/lib/x86_64-linux-gnu/libfoo
  • /usr/lib/libfoo (armel) —> /usr/lib/arm-linux-gnueabi/libfoo
  • /usr/lib/libfoo (i386) —> /usr/lib/i386-linux-gnu/libfoo

GNU triplets are used for architecture paths, with some adjustment
for historical cruft. While I do not particularly like the proposed names for the architecture specific directories, the general idea has merit.

The fundamental idea is that libraries have a canonical path:

  • Native and non-native locations are the same
  • 32/64 special casing goes away (/emul/ia32-linux)
  • Cross build and runtime locations are the same
  • No more /usr/<triplet>/lib for build-time linking
  • Emulated locations are the same (qemu, solaris on linux)

Why should you now be interested in Multiarch? Well, it turns out that Debian and Ubuntu are implementing Multiarch. Not all the work is done yet as major change to the packing tools were required (see dpkg). Also all relevant packages have to be rebuild as an extra Multiarch field to allow co-installability is required. The Multiarch field can be one of the following:

  • same: (libraries) Can be co-installed and can only satisfy deps within the arch.
  • foreign: (tools) Cannot be co-installed. Can satisfy deps for any arch.
  • allowed: (both) Can be either. Depending packages specify which.

See here for more information. The Multiarch specification is available here. No word from Fedora or Red Hat on whether they are working on a similar concept.

Comments are closed.