Multiarch Architecture Specifiers (Tuples)
This document describes the new schema for representing architecture ABIs as directory names, using normalized GNU triplets.
The abandoned proposal can be found at Multiarch/TuplesAbandoned.
This page is part of the larger effort to implement Multiarch library handling on Linux. For more information about Multiarch, see Multiarch, https://wiki.ubuntu.com/MultiarchSpec.
Contents
The problem
Multiarch specifies a method of making libraries for multiple, mutually-incompatible architectures installable on a single filesystem in a manner that ensures the same binaries can be used without modification on any system. To accomplish this, we require unique identifiers for each architecture that identifies an incompatible set of libraries that we want to be co-installed. We want these identifiers to be specified in as vendor-neutral a manner as possible, to ensure we retain maximal binary compatibility across Linux distributions.
Why not use GNU triplets?
Earlier proposals for multiarch did use GNU triplets as the components of the library path. Proof-of-concept implementations ran into two distinct cases where GNU triplets could not be used effectively in a cross-distribution manner:
- On IA-32, the GNU triplet varies according to the precise instruction set being targeted: e.g., i486-linux-gnu, i586-linux-gnu i686-linux-gnu. Such triplets will be inconsistent over time within a single distribution as compiler defaults are changed, let alone between distributions.
On ARM, the canonical GNU triplet for EABI systems, whether using hard-float or soft-float, is arm-linux-gnueabi, despite the fact that hard-float and soft-float libraries use different calling conventions and can't be intermixed. The advice given by upstream GCC developers was to use the vendor field in the GNU triplet to express this difference1; however, the vendor field is private by design, making this unreliable for cross-distribution use.
Used solution
Use normalized GNU triplets for most tuples, and extend the GNU triplet when it is ambiguous.
multiarch name
syscall ABI
instruction set
endianness
wordsize
status
description
alpha-linux-gnu
linux
Alpha
little
64
port
foo bar ...
arm-linux-gnueabi
linux
ARM
little
32
release
foo bar ...
arm-linux-gnueabihf
linux
ARM
little
32
release
foo bar ...
hppa-linux-gnu
linux
PA-RISC
big
64
port
foo bar ...
i386-gnu
Hurd
IA-32
little
32
port
foo bar ...
i386-linux-gnu
linux
IA-32
little
32
release
foo bar ...
ia64-linux-gnu
linux
IA-64
big
64
release
foo bar ...
amd64-kfreebsd-gnu
linux
x86_64
little
32
release
foo bar ...
i386-kfreebsd-gnu
linux
IA-32
little
32
release
foo bar ...
m68k-linux-gnu
linux
MC68000
big
32
port
currently, 68020; gcc multilib could do 68040 and 68060 but is disabled as there is no infrastructure to actually make use out of it; Coldfire-MMU port's status is unclear (the decision on whether it'll share this multiarch tuple will probably be deferred until it's clear how exactly m68k and CF relate to each other, i.e. how much code sharing is done, whether it's one or two full or a full and an incomplete port, etc.)
mips-linux-gnu
linux
MIPS
big
32
release
foo bar ...
mipsel-linux-gnu
linux
MIPS
little
32
release
foo bar ...
mips-linux-gnuabin32
linux
MIPS
big
64
biarch
glibc, MIPS n64 ABI
mipsel-linux-gnuabin32
linux
MIPS
little
64
biarch
glibc, MIPS n64 ABI
mips64-linux-gnuabi64
linux
MIPS64
big
64
biarch
foo bar ...
mips64el-linux-gnuabi64
linux
MIPS64
little
64
biarch
foo bar ...
powerpc-linux-gnu
linux
Power
big
32
release
glibc, SYSV hard-float ABI (biarch is ppc64)
powerpc-linux-gnuspe
linux
Power
big
32
port
glibc, SYSV soft-float ABI, uses e500v2 SPE FPU
ppc64-linux-gnu
linux
Power
big
64
biarch
glibc, EABI, partial biarch of "powerpc"
s390-linux-gnu
linux
System/390
big
32
release
foo bar ...
s390x-linux-gnu
linux
z/Architecture
big
32
port
foo bar ...
sparc-linux-gnu
linux
SPARC
big
32
release
foo bar ...
sparc64-linux-gnu
linux
SPARC
big
64
port
foo bar ...
x86_64-linux-gnu
linux
x86_64
little
64
release
foo bar ...
The status describes if the name is used in a (to be) released version of Debian and/or Ubuntu (release), if it is a new or abandoned port on Debian Ports (port), or if it's used as a name for a Debian gcc multilib configuration (biarch).
Supporting interfaces
- dpkg-architecture -qDEB_HOST_MULTIARCH (on dpkg based systems).
- gcc -print-multiarch (proposed patch; currently only available in Debian wheezy (unreleased), and in Ubuntu 11.10 (oneiric) or newer.
To avoid divergent embedded implementations of architecture->tuple mappings in every piece of software that wants to make use of these paths, a standard commandline tool that encapsulates this mapping should be provided, similar to the config.guess and config.sub tools that are a standard part of GNU autotools. We recommend a name of lsb_architecture for this tool.