Я должен сообщить, что у меня мало опыта использования multilib-build.eclass
-style multilib в Gentoo.
ABI_X86
является USE_EXPAND
переменной; установка ABI_X86="32 64"
или USE="abi_x86_32 abi_x86_64"
эквивалентны. Настройка по умолчанию ABI_X86, на момент написания этой статьи (2013-09-09), для default/linux/amd64/13.0
профиля выглядит просто ABI_X86=64
.
Эта переменная управляет явной поддержкой multilib в ebuild, которые используют multilib-build.eclass
более похожий на Gentoo способ создания multilib, чем оригинальный метод.
Первоначальный метод установки 32-разрядных библиотек в Gentoo - использование имен двоичных снимков app-emulation/emul-linux-*
. Каждый из этих двоичных пакетов эмуляции содержит полный набор 32-битных библиотек, скомпилированных для вас некоторыми разработчиками Gentoo. Поскольку каждая из них устанавливает пакет библиотек, которые должны координироваться вместе, отслеживать зависимости 32-битных ebuild'ов сложнее. Например, если вам нужна 32-битная media-libs/alsa-lib
система в 32-битной системе, вы просто устанавливаете media-libs/alsa-lib
, но в 64-битной мультибиблиотечной системе вы должны обнаружить, что в app-emulation/emul-linux-soundlibs
числе прочих библиотек устанавливается 32-битная версия media-libs/alsa-lib
. Кроме того, разработчик Gentoo, создающий один такой бинарный пакет, должен выяснить причуды multilib и buildsystem каждого из них.из включенных в пакет моментальных снимков библиотек, что усложняет обслуживание. И, самое главное, предоставление бинарных пакетов в качестве единственного варианта официального варианта использования multilib в Gentoo противоречит духу Gentoo. Вы должны иметь право все компилировать самостоятельно!
В multilib-build.eclass
отдаляется от такого поведения, помогая отдельные сборочные установить как 32-разрядные , так и 64-разрядные версии. Это должно позволить, например, wine
указывать только зависимости непосредственно от пакетов, которые ему нужны, вместо того, чтобы загружать app-emulation/emul-linux-*
пакеты. Как упоминает ssuominen в ветке форума, на которую вы ссылались :
= app-emulation / emul-linux-x86-xlibs-20130224-r1, который является пустым пакетом, в котором нет файлов, поскольку файлы теперь поступают непосредственно из x11-libs /
(Обратите внимание, что с -r1
тех пор был переименован в -r2
) В конце концов, app-emulation/emul-linux-x86-xlibs
сам по себе должен быть удален , так как 32-битные пакеты соответствующим образом напрямую зависят от правильных пакетов, x11-libs
которые, с multilib-build.eclass
помощью, предоставляют необходимые 32-битные библиотеки. Это где ABI_X86
вступает в игру. Любой multilib-build.eclass
-Enabled пакет получает по крайней мере новые USE-флаги abi_x86_32
и abi_x86_64
и , вероятно abi_x86_x32
. Используя EAPI=2
-style USE-зависимости , пакеты могут зависеть от 32-битных версий других пакетов. Если x11-libs/libX11
появляется while ABI_X86="32 64"
, то он должен быть установлен с установленными USE-flags abi_x86_32
и abi_x86_64
USE-flags. Если конкретному графическому пакету требуется 32-битная версия libX11
, он может указатьx11-libs/libX11[abi_x86_32]
в его зависимостях. Таким образом, если вы попытаетесь установить этот графический пакет и libX11
не установили 32-битные библиотеки, portage откажется. multilib-build.eclass
Он также универсален и совместим с 32-битными системами: установка этого же графического пакета в 32-битной системе всегда будет работать, поскольку его невозможно установить libX11
без установленного abi_x86_32
флага использования. Это решает проблему необходимости зависеть от того, app-emulation/emul-linux-x86-xlibs
когда вы работаете в мультибиблиотечной системе и напрямую x11-libs/libX11
в 32-битной системе. Мы прокладываем путь к созданию более четких и разумных зависимостей между пакетами в мультибиблиотечных системах. =app-emulation/emul-linux-x86-xlibs-20130224-r2
существует как посредник, который позволяет любым старым пакетам, которые раньше зависели, от app-emulation/emul-linux-x86-xlibs
которых не знают, как напрямую зависеть, например, от того x11-libs/libX11[abi_x86_32]
, чтобы все еще работать.=app-emulation/emul-linux-x86-xlibs-20130224-r2
удостоверится, что существуют те же 32-разрядные библиотеки, /usr/lib32
как если бы =app-emulation/emul-linux-x86-xlibs-20130224
они были установлены, но делает это Gentoo путем построения этих 32-разрядных библиотек с помощью своих зависимостей, а не предоставления двоичного пакета. virtual
Таким образом, он ведет себя подобно пакетам в категории: он ничего не устанавливает, а просто «перенаправляет» зависимости для существующих ebuild.
Мы видели, как multilib-build.eclass
прокладывается путь к более чистым зависимостям в мультибиблиотечных системах. Любой пакет, у которого есть ABI_X86
параметры (то же самое, что и использование abi_x86_*
флагов использования), установил 32-битную версию самого себя, если вы указали USE=abi_x86_32
/ ABI_X86=32
. Как это работает (на высоком концептуальном уровне)? Вы можете прочитать сам ebuild. По сути, идея та же, что и в ebuild-файлах python или ruby, которые могут устанавливать себя одновременно для нескольких версий python и ruby. Когда ebuild наследует multilib-build.eclass
, он зацикливается на ABI_X86 и выполняет каждый шаг процесса распаковки, компиляции и установки для каждой записи в ABI_X86. Поскольку portage проходит все фазы ebuild, такие как src_unpack()
, src_compile()
и src_install()
(и другие) по порядку и только один раз,multilib-build.eclass
(в настоящее время, с помощью multibuild.eclass
) использует создает каталог для каждого отдельного значения ABI_X86. Он распакует копию источников в каждый из этих каталогов. Оттуда каждый из этих каталогов начинает расходиться, так как каждый нацелен на определенный ABI. Каталог для ABI_X86=32
будет ./configure --libdir=/usr/lib32
работать с 32-битным таргетингом FLAGS (например, CFLAGS=-m32
происходит из envvar CFLAGS_x86 профиля multilib (примечание: профили portage чаще всего называют ABI_X86 = 32 как ABI = x86 и ABI_X86 = 64 как ABI = amd64)). В течениеsrc_install()
На этапе все различные скомпилированные ABI устанавливаются поверх друг друга, поэтому, когда любые файлы имеют как 32-битную, так и 64-битную версии, выигрывает собственный ABI (например, ebuild, устанавливающий обе библиотеки и исполняемый файл в PATH, устанавливает только 64 -битный исполняемый файл в PATH, но включает в себя как 32-битные, так и 64-битные библиотеки). Резюмируя: при установке ABI_X86="32 64"
в make.conf
любой пакет , который поддерживает multilib-build.eclass
займет примерно в два раза больше работы (я не говорю , что время ;-)) для компиляции , как она строится один раз для каждого ABI и результаты в 32-битных библиотек в /usr/lib32
,
Я не знаю, есть ли официальная документация на данный момент ABI_X86
или ее подробный статус. Использование Ebuild'ов пока multilib-build.eclass
выглядит нестабильно. Вы можете следовать инструкциям в блоге, на который вы ссылаетесь, чтобы начать испытывать и тестировать, ABI_X86
если вы понимаете разницу между app-emulation/emul-linux-x86-xlibs-20130224
мультилибом нового стиля app-emulation/emul-linux-x86-xlibs-20130224-r2
. Но, если вы в порядке с бинарным пакетом старого стиля, я думаю, что он app-emulation/emul-linux-x86-xlibs-20130224
должен оставаться функциональным. Вам нужно будет перейти только в том -r2
случае, если вы используете какой-либо пакет, который напрямую зависит от abi_x86_32
флага использования другого пакета (например, app-emulation/emul-linux-x86-xlibs-20130224
и x1-libs/libX11[abi_x86_32]
не может сосуществовать, поскольку они, вероятно, оба устанавливают одну и ту же библиотеку /usr/lib32
, а именно /usr/lib32/libX11.so.6
). быстроПосмотрите на wine-1.7.0.ebuild
подсказывает мне, что это не нужно -r2
.
app-emulation/emul-linux-x86
других, а другие зависели от их прямых аналогов. Потребовалось много изменений ключевых слов и USE-флагов, но у меня было все для того, чтобы скомпилировать и успешно работать вместе! :-DСуществует также флаг использования abi_x86_x32 (он отличается от abi_x86_32). Этот экспериментальный и предназначен для создания полу-64-битных приложений. Разница лишь в том, что они имеют 4-байтовые указатели. Это ограничивает использование памяти до 4 ГБ и в большинстве случаев снижает накладные расходы, а также позволяет использовать все 64-битные инструкции.
источник
В настоящее время ситуация настоящий ад. Кажется, проблема в том, что многие пакеты являются своего рода «полумаски» ... Я не знаю точной терминологии, но кажется, что некоторые пакеты имеют ключевое слово «~ amd64» с «abi_x86_32» и флагом использования и «amd64» без тот флаг использования ... В результате, во время моего обновления я включаю "abi_x86_32", но emerge по-прежнему устанавливает пакеты с ABI_X86 = "(64) (-32)", если я не добавлю "~ amd64" для каждого такого пакета. И если оно извлекается как зависимость, а не как непосредственное возникновение, то предложение autounmask-write для этого изменения не предлагается - emerge просто сообщает, что не может удовлетворить зависимость для этого пакета с необходимым флагом использования «abi_x86_32». Поэтому я должен добавить каждый пакет один за другим в package.keywords с помощью «~ amd64». Это много ручной работы ... И для какой версии пакета я должен это сделать? Я не могу сказать, что я на самом деле хочу, а именно «для версий, где он помечен как« amd64 »без этого флага использования». Я могу либо поставить конкретную последнюю версию, которую я вижу сейчас, и тем самым усложнить ее будущие обновления, либо поставить все версии, а затем, возможно, установить версии, которые не помечены как стабильные даже для 64-разрядных ...
источник
my-category/package
ихpackage.keywords
, portage будет автоматически интерпретировать это как принятие любого~amd64
(принимая вашеARCH=amd64
). Вы можете получить только поведение , вы можете описать (совпадающие версии без с~amd64
флагом) , если вы говорите что - то вродеmy-category/package **
.Косвенно связанная информация: На сегодняшний день полная система рабочего стола KDE на systemd может быть скомпилирована простым мультибиблиотечным способом (без пакетов эмуляции). Единственная проблема теперь - это проприетарный пакет nvidia-drivers, но это можно решить, перейдя с открытым исходным кодом.
Как начать (другие ссылки включены): https://forums.gentoo.org/viewtopic-t-985380-highlight-.html
Статус переноса Gentoo Multilib https://wiki.gentoo.org/wiki/Multilib_porting_status
источник