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

• ru
• Multiarch
• HOWTO

Multiarch позволяет вам устанавливать пакеты, предназначенные для различных архитектур на одну и ту же машину. Это полезно для различных задач, но наиболее общая задача — установка 64 и 32-битных программ на одной машине с автоматическим разрешением зависимостей. В общем, вы можете иметь библиотеки более чем одной архитектуры установленные вместе и приложения для той или иной архитектуры, установленные как альтернативы. Заметьте что при этом не обязательно версии приложений под различные архитектуры должны быть установлены вместе.

Чтобы узнать текущую архитектуру, набираем dpkg --print-architecture. (Обратите внимание, что архитектура на самом деле относится к «ABI» (Application Binary Interface), а не набор инструкций (ISA). Так, например, armel и armhf различные архитектуры потому, что они имеют различные вызовы библиотек ABIs, хотя используют одинаковый набор инструкций.

Пакеты можно указывать как ‘package:architecture’, например libc:i386 и libc:amd64, обратите внимание что семантика в dpkg и apt немного отличается, поэтому вы можете получить различные результаты, но они всегда будут безопасны и не двусмысленны. Имя пакета ‘package’, всегда будет соответствовать текущей архитектуре apt.

Доступные архитектуры можно посмотреть dpkg --print-foreign-architectures.dpkg будет управлять пакетами для этих архитектур, а также архитектуры машины.

Заголовок ‘Multi-Arch’ в пакете соответствует всем multiarch-aware пакетам.

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.

Использование

Конфигурация архитектур

Чтобы добавить дополнитульную архитектуру (в Debian для dpkg 1.16.2 и выше):

Обратите внимание: ничего не изменится, пока не обновите список пакетов.

Для удаления архитектуры

dpkg архитектуры хранятся в /var/lib/dpkg/arch.

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.

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

Note: There is a bug in apt versions >=0.9.7 and

after adding new architectures.

Установка/удаление пакетов

Для установки пакета из архитектуры не по-умолчанию, нужно ввести в командной строке:

Зависимости пакета будут установлены автоматически, для корректной архитектуры пример:

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

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:

Источник

Debian: простое превращение i386 в amd64

Это краткая статья о том, как без переустановки организовать 64-битную архитектуру на вашем 32-битном Debian/Deabian-based дистрибутиве (который вы могли по-невнимательности загрузить вместо 64bit).

* Ваше железо должно изначально поддерживать amd64, магию творить никто не собирается.
* Это может повредить систему, так что действуйте очень осторожно.
* Всё проверялось на Debian10-buster-i386.
* Не делайте этого, если хоть что-то здесь не понимаете.

Dpkg, apt и sources.list

Сразу к делу, если вы сумaсшедший всё взвесили, начинаем подготовку пакетов (в принципе здесь порядок не имеет значения, но по пунктам удобнее)

1. Выбираем amd64 в /etc/apt/sources.list, вставляя ‘ [arch=amd64] ‘ между deb\deb-src и URL

Это нужно для того, чтобы в будущем загружались только 64-х битные пакеты.

2.Добавляем amd64 в dpkg, чтобы он не ругался:

3.Обновляем список пакетов:

Разумеется всё это не имеет смысла без 64-х битного ядра, поэтому устанавливаем его:

Место $VERSION подставить нужную версию ядра.

После установки ядра grub перенастроится автоматически.

Завершение

После перезагрузки наша система уже сможет работать с amd64, но с пакетами могут возникнуть некоторые проблемы. У меня для их решения было достаточно выполнить данные команды:

Хотя сильно на этот счёт беспокоиться тоже не стоит — все нужные пакеты со временем сами установятся как зависимости, а ненужные удаляются так:

Источник

LiveInternetLiveInternet

—Поиск по дневнику

—Подписка по e-mail

—Постоянные читатели

—Статистика

Добавление/удаление 32/64-bit архитектур в Ubuntu Linux

Добавление/удаление 32/64-bit архитектур в Ubuntu Linux

Как добавить/удалить 32-bit/64-bit архитектуру в Ubuntu Linux, вы задавались данным вопросом? Решение есть.

Так вот, например работая на компьютере с 32-bit архитектурой, вы хотите установить приложение которое не доступно для вашей архитектуры, но доступно для 64-bit, в данном случае есть выход. Конечно не всегда он срабатывает, но выручает часто.

Наведу пример, скачали мы пакет определенного приложения, пускай это будет pak-name-amd64.deb, вам нужно установить данный пакет в Ubuntu, вы попробуете конечно выполнить установку пакета подобным способом:

pak-name-amd64.deb is for architecture amd64 ; the package cannot be built on this system

sudo dpkg —add-architecture amd64
sudo apt-get update

• После вы увидите сообщение, что система нам предлагает установить пакеты которые не смогли установиться ранее из-за ошибок, просто жмем клавишу — Enter и установка пакетов должна пройти гладко(гарантий нет), у меня это происходило без ошибок.

В общем, установили мы приложение и вроде-бы все работает, не забываем удалить 64-bit архитектуру с системы которую мы ранее добавили, так как у нас архитектура 32-bit, выполним в терминале команду:

sudo dpkg —remove-architecture amd64
sudo apt-get update

• На данном этапе мы решили вопрос установки приложения под 64-bit архитектуру. Аналогичное мы можем проделать и для приложений под 32-bit архитектуру если у нас основная 64-bit, делаем по тому же принципу.

Есть у нас условный пакет с названием — pak-name-i386.deb.
Добавим 32-bit архитектуру в систему:

sudo dpkg —add-architecture i386
sudo apt-get update

• Данная команда проверит и предложит установить пакеты которые не были установлены из-за ошибок при нашей попытке установки приложения выше.

После данных манипуляций так же не забываем удалить 32-bit архитектуру если у вас основная 64-bit, выполним в терминале команду:

sudo dpkg —remove-architecture i386
sudo apt-get update

Выбор ранее не выбранного пакета teamviewer.
(Чтение базы данных … на данный момент установлено 315507 файлов и каталогов.)
Распаковывается пакет teamviewer (из файла ./teamviewer_amd64.deb) …
dpkg: зависимости пакетов не позволяют настроить пакет teamviewer:
teamviewer зависит от lib32asound2, однако:
Пакет lib32asound2 не установлен.
teamviewer зависит от lib32z1, однако:
Пакет lib32z1 не установлен.
teamviewer зависит от ia32-libs, однако:
Пакет ia32-libs не установлен.

dpkg: ошибка при обработке параметра teamviewer (—install):
проблемы зависимостей — оставляем не настроенным
При обработке следующих пакетов произошли ошибки:
teamviewer

sudo dpkg —add-architecture i386
sudo apt-get update

sudo dpkg —remove-architecture i386
sudo apt-get update

/Загрузки# dpkg -i teamviewer_10.0.46203_i386.deb
Выбор ранее не выбранного пакета teamviewer.
(Чтение базы данных … на данный момент установлено 243957 файлов и каталогов.)
Preparing to unpack teamviewer_10.0.46203_i386.deb .
Unpacking teamviewer (10.0.46203) .
dpkg: зависимости пакетов не позволяют настроить пакет teamviewer:
teamviewer зависит от libjpeg62, однако:
Пакет libjpeg62 не установлен.

dpkg: error processing package teamviewer (—install):
проблемы зависимостей — оставляем не настроенным
При обработке следующих пакетов произошли ошибки:
teamviewer

• Что мы делаем в данном случае чтобы приложение подтянуло нужные ему пакеты и установилось до конца и у нас была возможность работать с приложением TeamViewer.

Достаточно в этой ситуации просто выполнить команду:

• Далее согласиться установить пакеты нажав на клавишу Enter. Как видим неустановленные пакеты подтянулись и приложение удачно установилось.

Так же если кому интересно, советовал бы посмотреть видео, так же узнаете некоторые дополнительные команды:

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

Источник

• Multiarch
• HOWTO

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.

Being able to actually *run* the installed packages completely depends on the kernel and possible qemu-user configuration:

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.

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 ‘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):

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:

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.

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

Note: There is a bug in apt versions >=0.9.7 and

after adding new architectures.

Installing/removing packages

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

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

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

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:

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.

The purpose of :native is to request a package for the build architecture instead of the host architecture while satisfying cross Build-Depends.

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.

You cannot use :any unless the target package is marked Multi-Arch: allowed. Doing so anyway usually results in the dependency becoming unsatisfiable.

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.

Источник