Linux добавить архитектуру i386

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.

• either the kernel supports a compatibility interface, notably 64bit kernels often support running 32bit software (but most probably not the converse)
• or a qemu-user instance is configured to act as an on-the-fly emulation layer, see QemuUserEmulation

Notably, while Multiarch allows to install packages for a different kernel, e.g. Hurd or kFreeBSD binaries on a Linux system or vice-versa, running them will *not* work, one really needs to run a full VM to run the corresponding actual kernel and run the binaries inside them.

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.

• 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 ‘debhelper:amd64’ will satisfy a dependency on debhelper 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 armhf

Note that nothing will really change until you do an

to update the available package lists.

To remove an architecture

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

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

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= to set the default architecture or APT::Architectures=» «.

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.

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

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

Installing cross-dependencies

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

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

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

When to use :native and when to use :any?

The purpose of :any is to annotate a dependency and indicate that the architecture of the target package does not matter. In practice, it does matter though as one usually wants it to be executable, but dpkg has no concept of an architecture being executable on a particular processor. So in practice, you almost always get a native package when you annotate :any. The native architecture is defined to be the architecture of the dpkg package. While package building, the native architecture usually equals the build architecture.

1. You cannot use :native in binary package dependencies. It is only applicable to Build-Depends. Doing so anyway usually results in a dependency parsing error.
2. You cannot use :any unless the target package is marked Multi-Arch: allowed. Doing so anyway usually results in the dependency becoming unsatisfiable.
3. If you have a choice between :any and :native and your target package is a python interpreter, you should use :any, because dh-python parses the dependency and fails on :native.

Источник

Как запустить 32-битное приложение на 64-битном Linux

Почти каждая система Linux имеет как 32-битную, так и 64-битную архитектуру. Но проблема в том, что по умолчанию приложение, написанное для работы на 32-битной системе, не будет работать на 64-битной системе и наоборот. Это может быть очень неприятно, поскольку никто не хочет разрабатывать два исходных кода для одного и того же приложения или поддерживать два отдельных бинарных файла для разных архитектур. Вы можете решить эту проблему, сделав так, чтобы 32-битная программа могла работать на 64-битной архитектуре. В этой статье мы узнаем, как запустить 32-битное приложение на 64-битном Linux.

Как запустить 32-битное приложение на 64-битном Linux

Ниже описаны шаги для запуска 32-битных приложений в 64-битной системе Linux. Чтобы иметь возможность запускать 32-битные программы на 64-битной системе Linux, такой как Ubuntu, необходимо добавить архитектуру i386 и установить 3 библиотечных пакета libc6:i386, libncurses5:i386 и libstdc++6:i386.

1. Добавьте архитектуру i386

Откройте терминал и выполните следующую команду.

sudo dpkg --add-architecture i386

2. Установите необходимые библиотеки пакетов

Затем выполните следующую команду для установки 3 библиотек пакета.

sudo apt-get update sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386

Если вышеуказанная команда не сработала, выполните следующую команду.

sudo apt-get install multiarch-support

3. Выполните 32-битную программу

Теперь вы должны иметь возможность запустить 32-битную программу на 64-битной системе. Замените приведенное ниже sample32bitprogram на имя файла бинарного файла вашей программы.

Если вы используете несовместимую версию gcc на вашей системе Ubuntu, вы можете получить ошибку при выполнении вышеуказанных команд, вам может потребоваться обновить gcc с помощью следующей команды.

sudo apt-get install gcc-multilib

Заключение

В этой статье мы узнали, как запускать 32-битные программы на 64-битных, не создавая отдельные бинарные файлы как для 32-битных, так и для 64-битных систем.

Похожие записи:

Источник

Как проверить включена ли в dpkg архитектура i386

Исполнимые файлы различаются в зависимости от архитектуры центрального процессора — 64-битные или 32-битные. Следовательно, различаются и установочные пакеты, которые собраны для той или иной архитектуры.

64-битные пакеты обозначаются как amd64. По умолчанию в дистрибутивах Linux включена поддержка пакетов только той архитектуры, которая соответствует центральному процессору, сейчас это практически всегда 64-битный ЦПУ. Но иногда возникает необходимость установить 32-битные библиотеки или приложения. Это может понадобиться, например, для кросскомпиляции или, более близкий для рядового пользователя пример, для программы Wine, чтобы она могла поддерживать максимальный спектр запускаемых приложений.

Для проверки архитектуры вашего компьютера вы можете использовать команду (точнее говоря, это архитектура пакетов, которые устанавливает dpkg, но обычно это одно и то же):

Для добавления поддержки архитектуры i386 (32-бита) используется команда:

sudo dpkg --add-architecture i386 sudo apt update

Как узнать, была ли подключена поддержка не родных архитектур и каких именно? Это можно сделать командой:

dpkg --print-foreign-architectures

значит архитектура i386 уже включена.

Кстати, отдельные пакеты можно установить без добавления посторонних архитектур с помощью опции —force-architecture, например:

sudo dpkg --force-architecture -i ПАКЕТ

Архитектуру можно удалить (кроме той, которая выводится опцией —print-architecture) с помощью команды вида:

sudo dpkg --remove-architecture АРХИТЕКТУРА

sudo dpkg --remove-architecture i386

Но если в вашей системе установлены пакеты удаляемой архитектуры, то операция будет отклонена.

Список подключённых архитектур хранится в файле /var/lib/dpkg/arch.

Связанные статьи:

Источник