Differences between revisions 1 and 34 (spanning 33 versions)
Revision 1 as of 2012-05-14 18:53:11
Size: 4533
Editor: wookey
Comment: Start HOWTO page on multiarch
Revision 34 as of 2017-02-09 10:01:46
Size: 8014
Editor: xerz
Comment: Added Spanish translation to the translations list
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Multiarch lets you install packages from multiple architectures on the same machine. This is useful in various ways, but the most common is installing both 64 and 32-bit software on the same machine and having dependencies correctly resolved automatically. #language en
~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: [[pt_BR/Multiarch/HOWTO|Brasileiro]] - English - [[es/Multiarch/HOWTO|Español]] - [[fr/Multiarch/HOWTO|Français]] - [[ru/Multiarch/HOWTO|Русский]]-~
----

 <<TableOfContents(2)>>

= What is this Multiarch? =

Multiarch lets you install library packages from multiple architectures on the same machine. This is useful in various ways, but the most common is installing both 64 and 32-bit software on the same machine and having dependencies correctly resolved automatically. In general you can have libraries of more than one architecture installed together and applications from one architecture or another installed as alternatives. Note that it does not enable multiple architecture versions of ''applications'' to be installed simultaneously.
Line 5: Line 13:
There is a current machine architecture, as printed by {{{dpkg --print-architecture}}}. It is built-in to the currently installed dpkg package. There is a current machine architecture, as printed by {{{dpkg --print-architecture}}}. It is built-in to the currently installed dpkg package. 
Line 7: Line 15:
Packages are now specified as 'Package:Architecture' pretty-much anywhere that was previously just 'Package', so we have libc:i386 and lib:amd64. The bare name 'package' refers to the current machine architecture. ( Note that ''architecture'' here actually refers to an 'ABI' (Application Binary Interface), not an instruction set (ISA). So for example, ''armel'' and ''armhf'' are different ''architectures'', even though they use (near enough) the same instruction set, because they have different library-calling ABIs. )

Packages can now be specified as 'package:architecture' pretty-much anywhere that was previously just 'package', so we have libc:i386 and libc:amd64, unfortunately the semantics in dpkg and apt are slightly different so you might get different results, but it should always be safe and unambiguous to arch-qualify packages. The bare name 'package' refers to the current machine architecture in apt.
Line 18: Line 28:
Packages marked 'Multi-Arch : allowed also exist which can be treated as either :same or :foreign depending on how they are depended-on. See the multiarch spec and implementationhowto for details of this. Packages marked 'Multi-Arch : allowed also exist which can be treated as either :same or :foreign depending on how they are depended-on.

Packagers are currently working through the distro, starting with the most useful packages for making multi-arch aware. See the [[UbuntuWiki:MultiarchSpec|multiarch spec]] and [[Multiarch/Implementation|implementation howto]] for details of how it all actually works, and how to update packages to take advantage of the functionality.
Line 24: Line 36:
check dpkg support is present with
{{{
dpkg --assert-multiarch
}}}
In Debian dpkg this is present since 1.16.2. In Ubuntu this is present since natty (v1.15.8.10ubuntu1). Check by seeing if {{{dpkg --print-foreign-architectures}}} is understood.
Line 29: Line 38:
In Debian this is present since 1.16.2. In Ubuntu this is present since natty (v1.16.0) Apt is multiarch-aware if it supports {{{-o APT::Architectures}}}. This is available from version 0.8.13 onwards. However there are many multiarch-related improvements and bug-fixes in later apt versions (some required by Debian dpkg 1.16.2 to properly enable multiarch), such as apt-get build-dep -a cross-dependency support, so the later the better in general up to at least 0.9.4.
Line 31: Line 40:
Apt is multiarch-aware if it supports -o APT::Architectures. This is available from version 0.8.13 onwards. However there are many multiarch-related improvements and bug-fixes in later apt versions, such as apt-get build-dep -a cross-dependency support, so the later the better in general up to at least 0.9.4. Prior to apt 0.9 in Debian, dpkg can get stuck (but only if multiarch is enabled) during upgrades when it is not told which arch package it should be configuring by apt. (dpkg: error: --configure needs a valid package name but 'gcc-4.7-base' is not: ambiguous package name 'gcc-4.7-base' with more than one installed instance) {{{dpkg --configure -a}}} will unbung this.
Line 37: Line 46:
To add an extra parchitecture: To add an extra architecture (in Debian from dpkg 1.16.2 onwards):
Line 42: Line 51:
dpkg-architecture --add-architecture armhf dpkg --add-architecture armhf
Line 45: Line 54:
To remove an achitecture
Note that nothing will really change until you do an
{{{
apt-get update
}}} to update the available package lists.


To remove an architecture
Line 52: Line 68:
== setting up apt sources == Note that you need to remove all packages of that architecture before removing it:
{{{
apt-get purge ".*:<arch>"
}}}
Line 54: Line 73:
Apt defaults to using the set of architectures reported by dpkg, and any unqualified architecture deb lines in {{{/etc/apt/sources.list}}}, which is usually what you wanted. This can be overridden using APT::Architecture=<arch> to set the defalt architecture or APT::Architectures="<arch> <arch>". Note that the Ubuntu dpkg in natty (1.16.0~ubuntu7 (reports 1.15.8.10)), oneiric and precise (1.16.1.2ubuntu7) uses a different syntax:
{{{
echo "foreign-architecture armhf" >> /etc/dpkg/dpkg.cfg.d/architectures
}}}
Line 56: Line 78:
apt-sources can be architecture qualified with this syntax. This is very useful on Ubuntu's split archive. It is not normally necessary on Debian unless your normal archive does not mirror the extra architectures you are intereted in. == Setting up apt sources ==

Apt defaults to using the set of architectures reported by dpkg, and any unqualified architecture deb lines in {{{/etc/apt/sources.list}}}, which is usually what you wanted. This can be overridden using APT::Architecture=<arch> to set the default architecture or APT::Architectures="<arch> <arch>".

apt-sources can be architecture qualified with this syntax. This is very useful on Ubuntu's split archive. It is not normally necessary on Debian unless your normal archive does not mirror the extra architectures you are interested in.
Line 58: Line 84:
deb [arch=amd64.i386] http://uk.archive.ubuntu.com/ubuntu/ quantal main universe deb [arch=amd64,i386] http://uk.archive.ubuntu.com/ubuntu/ quantal main universe
Line 63: Line 89:
Don't forget to {{{apt-get update}}} after adding new architectures. Note: There is a bug in apt versions >=0.9.7 and <0.9.7.2 which means that putting 'arch=armel,armhf' on one line didn't work - you needed two separate entries.

Don't forget to
{{{
apt-get update
}}}
after adding new architectures.
Line 78: Line 110:
dpkg --i package:architecture dpkg -i package_version_architecture.deb
dpkg
-r package:architecture
Line 81: Line 114:
Sometimes (in May 2012) dpkg get stuck when it is not sure which arch package it should be configuring. (dpkg: error: --configure needs a valid package name but 'gcc-4.7-base' is not: ambiguous package name 'gcc-4.7-base' with more than one installed instance) {{{dpkg --configure -a}}} will unbung this.
Line 90: Line 122:
Details of how this resolves are on the This only works when all the 'tools' packages depended-on are marked {{{Multi-Arch: foreign}}}, any depended-on libraries which are also needed on the BUILD machine, and -dev packages which are needed for both HOST and BUILD architectures are made co-installable ('Multi-Arch: same' with arch-qualified paths), and any exceptions to the default rules are marked {{{package:any}}} or {{{package:native}}} in the package source. This process is ongoing.

When it doesn't work you can often get the dependencies installed with a manual apt-get line:
e.g instead of {{{
apt-get build-dep -a armhf acl
}}}, do
{{{
apt-get install autoconf automake debhelper gettext libtool libattr1-dev:armhf
}}}

Details of how this resolves are on UbuntuWiki:MultiarchCross.

== Installing Android SDK compat libraries ==

Some users using the Android SDK might encounter problems when trying to run build-tools or platform-tools on amd64 bit platform. As replacement for {{{ia32-libs}}}, users should be fine just installing the following libraries:

{{{
dpkg --add-architecture i386
apt-get update
apt-get install libstdc++6:i386 libgcc1:i386 zlib1g:i386 libncurses5:i386
}}}
----
## This page is referenced from http://www.debian.org/releases/wheezy/amd64/release-notes/ch-whats-new
CategoryPermalink

Translation(s): Brasileiro - English - Español - Français - Русский


What is this Multiarch?

Multiarch lets you install library packages from multiple architectures on the same machine. This is useful in various ways, but the most common is installing both 64 and 32-bit software on the same machine and having dependencies correctly resolved automatically. In general you can have libraries of more than one architecture installed together and applications from one architecture or another installed as alternatives. Note that it does not enable multiple architecture versions of applications to be installed simultaneously.

Concepts

There is a current machine architecture, as printed by dpkg --print-architecture. It is built-in to the currently installed dpkg package.

( Note that architecture here actually refers to an 'ABI' (Application Binary Interface), not an instruction set (ISA). So for example, armel and armhf are different architectures, even though they use (near enough) the same instruction set, because they have different library-calling ABIs. )

Packages can now be specified as 'package:architecture' pretty-much anywhere that was previously just 'package', so we have libc:i386 and libc:amd64, unfortunately the semantics in dpkg and apt are slightly different so you might get different results, but it should always be safe and unambiguous to arch-qualify packages. The bare name 'package' refers to the current machine architecture in apt.

Other available architectures are shown by dpkg --print-foreign-architectures. dpkg will manage packages for these architectures as well as the machine architecture.

There is a 'Multi-Arch' header in the package metadata of any multiarch-aware package.

Existing packages work fine in a multiarch environment, just as before, but to gain the benefits of co-installation or cross-architecture dependencies, many packages need to be made 'multiarch-aware'.

  • For an unchanged package you can choose which arch version of a package to install (e.g. 'amd64' or 'i386').
  • If a package is marked 'Multi-Arch: foreign', then it can satisfy dependencies of a package of a different architecture (e.g 'make:amd64' will satisfy a dependency on make for any-architecture package).
  • To enable more than one architecture version of a package to be installed at the same time (generally libraries and dev- packages) files need to be moved so they don't clash. These packages are marked 'Multi-Arch: same'.

Packages marked 'Multi-Arch : allowed also exist which can be treated as either :same or :foreign depending on how they are depended-on.

Packagers are currently working through the distro, starting with the most useful packages for making multi-arch aware. See the multiarch spec and implementation howto for details of how it all actually works, and how to update packages to take advantage of the functionality.

Availability

You need a multiarch-aware dpkg and apt.

In Debian dpkg this is present since 1.16.2. In Ubuntu this is present since natty (v1.15.8.10ubuntu1). Check by seeing if dpkg --print-foreign-architectures is understood.

Apt is multiarch-aware if it supports -o APT::Architectures. This is available from version 0.8.13 onwards. However there are many multiarch-related improvements and bug-fixes in later apt versions (some required by Debian dpkg 1.16.2 to properly enable multiarch), such as apt-get build-dep -a cross-dependency support, so the later the better in general up to at least 0.9.4.

Prior to apt 0.9 in Debian, dpkg can get stuck (but only if multiarch is enabled) during upgrades when it is not told which arch package it should be configuring by apt. (dpkg: error: --configure needs a valid package name but 'gcc-4.7-base' is not: ambiguous package name 'gcc-4.7-base' with more than one installed instance) dpkg --configure -a will unbung this.

Usage

Configuring architectures

To add an extra architecture (in Debian from dpkg 1.16.2 onwards):

dpkg --add-architecture <arch>

e.g.

dpkg --add-architecture armhf

Note that nothing will really change until you do an

apt-get update

to update the available package lists.

To remove an architecture

dpkg --remove-architecture <arch>

dpkg architectures are stored in /var/lib/dpkg/arch.

Note that you need to remove all packages of that architecture before removing it:

apt-get purge ".*:<arch>"

Note that the Ubuntu dpkg in natty (1.16.0~ubuntu7 (reports 1.15.8.10)), oneiric and precise (1.16.1.2ubuntu7) uses a different syntax:

echo "foreign-architecture armhf" >> /etc/dpkg/dpkg.cfg.d/architectures

Setting up apt sources

Apt defaults to using the set of architectures reported by dpkg, and any unqualified architecture deb lines in /etc/apt/sources.list, which is usually what you wanted. This can be overridden using APT::Architecture=<arch> to set the default architecture or APT::Architectures="<arch> <arch>".

apt-sources can be architecture qualified with this syntax. This is very useful on Ubuntu's split archive. It is not normally necessary on Debian unless your normal archive does not mirror the extra architectures you are interested in.

deb [arch=amd64,i386] http://uk.archive.ubuntu.com/ubuntu/ quantal main universe
deb [arch=armel,armhf] http://ports.ubuntu.com/ubuntu-ports quantal main universe

Arch-qualifying deb-src lines doesn't make any sense.

Note: There is a bug in apt versions >=0.9.7 and <0.9.7.2 which means that putting 'arch=armel,armhf' on one line didn't work - you needed two separate entries.

Don't forget to

apt-get update

after adding new architectures.

Installing/removing packages

To install a package of the non-default architecture just specify that architecture on the command line:

apt-get install package:architecture

That package's dependencies will be installed automatically for the correct architectures (same-arch library deps, machine-arch for other deps) e.g

apt-get install links:i386

dpkg -i package_version_architecture.deb
dpkg -r package:architecture

Installing cross-dependencies

To install build-dependencies of a package before cross-building:

apt-get build-dep -a <arch> <package>

This only works when all the 'tools' packages depended-on are marked Multi-Arch: foreign, any depended-on libraries which are also needed on the BUILD machine, and -dev packages which are needed for both HOST and BUILD architectures are made co-installable ('Multi-Arch: same' with arch-qualified paths), and any exceptions to the default rules are marked package:any or package:native in the package source. This process is ongoing.

When it doesn't work you can often get the dependencies installed with a manual apt-get line: e.g instead of

apt-get build-dep -a armhf acl

, do

apt-get install autoconf automake debhelper gettext libtool libattr1-dev:armhf

Details of how this resolves are on MultiarchCross.

Installing Android SDK compat libraries

Some users using the Android SDK might encounter problems when trying to run build-tools or platform-tools on amd64 bit platform. As replacement for ia32-libs, users should be fine just installing the following libraries:

dpkg --add-architecture i386
apt-get update
apt-get install libstdc++6:i386 libgcc1:i386 zlib1g:i386 libncurses5:i386


CategoryPermalink