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

Прошло несколько месяцев с тех пор, как я обновил свою систему Gentoo. И, как вы можете себе представить, это означает, что мне нужно пересмотреть множество пакетов (и изменений в USE). У меня система "amd64" (multilib), но у меня много пакетов с ручным набором ключей из "~ amd64".

В любом случае, в этом обновлении я продолжаю видеть USE-флаги "ABI_X86". Что это? Это новая. В списке рассылки новостей нет ничего об этом.

Я нашел эту тему: http://forums.gentoo.org/viewtopic-t-953900-start-0.html . Казалось бы, это показывает, как его использовать, но есть ли «реальные» документы для этого? Что оно делает? Что я должен установить для "ABI_X86"? У меня есть мультибиблиотечная система. Я предполагаю, что хочу "64", но тогда что такое "32" и "x32"? Я запутался в том, что мне нужно сделать здесь.

Emerge много кричит о конфликтах слотов, и они, похоже, связаны с "ABI_X86" (я точно забыл об ошибках, но помню, что это был zlib).

Итак, есть ли «официальные» документы о том, что это ABI_X86такое и как им пользоваться?

Из нити, которую я связал, я нашел эту страницу: http://kicherer.org/joomla/index.php/en/blog/liste/29-transition-of-emul-packages-to-true-multilib , но я хочу чтобы узнать, что я делаю, прежде чем отправлять ключевые слова и редактировать свои make.conf.

PS У меня есть большинство пакетов "app-emulation / emul-linux-x86" (те, которые мне, казалось, были нужны в то время) в моем файле "package.keywords".

Я должен сообщить, что у меня мало опыта использования 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_64USE-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.

Существует также флаг использования 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-разрядных ...

Косвенно связанная информация: На сегодняшний день полная система рабочего стола KDE на systemd может быть скомпилирована простым мультибиблиотечным способом (без пакетов эмуляции). Единственная проблема теперь - это проприетарный пакет nvidia-drivers, но это можно решить, перейдя с открытым исходным кодом.

Как начать (другие ссылки включены): https://forums.gentoo.org/viewtopic-t-985380-highlight-.html

Статус переноса Gentoo Multilib https://wiki.gentoo.org/wiki/Multilib_porting_status