Использование ABI_X86 в хинду

Я должен раскрыть, что у меня есть использование небольшого опыта multilib-build.eclass- мультиlib стиля в хинду.

ABI_X86 a 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.

Это управление переменными явная поддержка мультиlib в ebuilds, которые используют multilib-build.eclass который является более подобным хинду способом сделать мультиlib, чем исходный метод.

Исходный метод, что 32-разрядные библиотеки были бы установлены в хинду, через двоичные названные снимки app-emulation/emul-linux-*. Каждый из этих двоичных пакетов эмуляции содержит полный набор 32-разрядных библиотек, скомпилированных некоторым хинду dev для Вас. Поскольку каждый устанавливает пакет библиотек, которые должны быть скоординированы вместе, отслеживая зависимости 32 битов только ebuilds более тверд. Например, если Вам нужно 32-разрядное media-libs/alsa-lib в 32-разрядной системе Вы просто устанавливаете media-libs/alsa-lib, но в 64-разрядной системе мультиlib, необходимо обнаружить это app-emulation/emul-linux-soundlibs установки, среди других библиотек, 32-разрядной версии media-libs/alsa-lib. Кроме того, хинду dev создание одного такого двоичного пакета должен сделать работу выяснения мультиlib и buildsystem причуд каждой из включенных библиотек в пакете снимка, делая обслуживание тяжелее. И самое главное обеспечивая двоичные пакеты, поскольку единственная опция чиновника опции для использования мультиlib в хинду идет вразрез с духом хинду. Необходимо иметь право скомпилировать все сами!

multilib-build.eclass переезжает от этого поведения, помогая отдельному ebuilds установить и 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- включенный пакет получает, по крайней мере, новые флаги ИСПОЛЬЗОВАНИЯ abi_x86_32 и abi_x86_64 и вероятно abi_x86_x32. Используя EAPI=2- разработайте зависимости от ИСПОЛЬЗОВАНИЯ, пакеты могут зависеть от 32-разрядных версий других пакетов. Если x11-libs/libX11 появляется в то время как ABI_X86="32 64", затем это должно быть установлено с флагами ИСПОЛЬЗОВАНИЯ abi_x86_32 и abi_x86_64 Флаги ИСПОЛЬЗОВАНИЯ установлены. Если для конкретного графического пакета нужна 32-разрядная версия libX11, это может указать x11-libs/libX11[abi_x86_32] в его зависимостях. Таким образом, при попытке появиться этот графический пакет и libX11 не установил 32-разрядный, освобождает, перевозка откажется. multilib-build.eclass также универсально и совместим с 32-разрядными системами: установка этого того же графического пакета в 32-разрядной системе будет всегда работать, потому что невозможно установить libX11 без abi_x86_32 useflag быть установленным. Это решает проблему необходимости зависеть от app-emulation/emul-linux-x86-xlibs когда в системе мультиlib и непосредственно в x11-libs/libX11 на 32 битах только система. Мы прокладываем путь к наличию более чистые и разумные зависимости межпакета от систем мультиlib. =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 был установлен, но делает это хинду путь путем создания этих 32-разрядных библиотек через его зависимости вместо того, чтобы обеспечить двоичный пакет. Это ведет себя во многом как пакеты в virtual категория этот путь: это ничего не устанавливает, просто "вперед" зависимости для существующего ebuilds.

Мы видели как multilib-build.eclass прокладывает путь к более чистым зависимостям от систем мультиlib. Любой пакет, который имеет ABI_X86 опции (то же самое, что это имеет abi_x86_* useflags), установил 32-разрядную версию себя, если Вы указали USE=abi_x86_32/ABI_X86=32. Как это работает (на высоком концептуальном уровне)? Можно считать сам ebuild. В основном идея совпадает с Python или рубином ebuilds, которые имеют опцию установить себя для нескольких версий Python и рубина одновременно. Когда ebuild наследовался multilib-build.eclass, это циклично выполняется по ABI_X86 и делает каждый шаг распаковки, компиляции и процесса установки для каждой записи в ABI_X86. Так как перевозка проходит все ebuild фазы как src_unpack(), src_compile(), и src_install() (и другие) в порядке и только однажды, multilib-build.eclass (в настоящее время, с помощью multibuild.eclass) использование создает каталог для каждого различного значения ABI_X86. Это распакует копию источников к каждому из этих каталогов. Оттуда, каждый из этих каталогов начинает отличаться, поскольку каждый нацелен на особый ABI. Каталог для ABI_X86=32 будет иметь ./configure --libdir=/usr/lib32 выполненный с ФЛАГАМИ, предназначающимися 32-разрядного (например, CFLAGS=-m32 прибывает из CFLAGS_x86 envvar профиля мультиlib (примечание: профили перевозки главным образом относятся к ABI_X86=32 как ABI=x86 и ABI_X86=64 как ABI=amd64)). Во время src_install() фаза, весь другой скомпилированный ABIs установлен друг по другу так, чтобы, когда любые файлы имеют и 32-разрядные и 64-разрядные версии, собственные победы ABI (например, ebuild, устанавливающий обе библиотеки и исполняемый файл в ПУТИ, установил бы только 64-разрядный исполняемый файл в ПУТЬ, но включал бы и 32-разрядные и 64-разрядные библиотеки). Суммировать: когда Вы устанавливаете ABI_X86="32 64" в make.conf, любой пакет, который поддерживает multilib-build.eclass возьмет примерно дважды объем работы (я не говорю время ;-)) для компиляции, поскольку он создается однажды для каждого ABI и результатов в 32-разрядных библиотеках в /usr/lib32.

Я не знаю, существует ли официальная документация для ABI_X86 все же или его подробное состояние. Использование Ebuilds multilib-build.eclass кажется, главным образом нестабилен на данный момент. Можно следовать инструкциям в блоге, с которым Вы связались начать испытывать и тестировать ABI_X86 если Вы понимаете различие между app-emulation/emul-linux-x86-xlibs-20130224 и модернизированный мультиlib app-emulation/emul-linux-x86-xlibs-20130224-r2. Но, если Вы соглашаетесь с двоичным пакетом старого стиля, я думаю это app-emulation/emul-linux-x86-xlibs-20130224 должен остаться функциональным. Необходимо было бы только переместиться в -r2 если Вы используете какой-либо пакет, который непосредственно зависит от другого пакета abi_x86_32 useflag (например, 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.