Використання ABI_X86 в Gentoo

Минуло кілька місяців, як я оновив свою систему Gentoo. І, як ви можете собі уявити, це означає, що мені потрібно пройти багато пакетів (і USE змін). Моя система "amd64" (multilib), але у мене є багато пакетів з ключовими словами вручну з "~ amd64".

У будь-якому випадку в цьому оновлення я постійно бачу прапорці "ABI_X86" USE. Що це? Це нове. У цьому "списку новин" немає нічого про це.

Я знайшов цю тему: 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сказати, що у Gentoo у мене мало досвіду використання -style multilib.

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.

Ця змінна керує явною підтримкою багатолітражів у ebuilds, яка використовує multilib-build.eclassбільш гентоподібний спосіб робити multilib, ніж оригінальний метод.

Оригінальний метод встановлення 32-розрядної бібліотеки в Gentoo - це бінарні знімки з назвою app-emulation/emul-linux-*. Кожен з цих двійкових пакунків емуляції містить цілий набір 32-бітових бібліотек, зібраних для вас деяким розробником Gentoo. Оскільки кожна з них встановлює набір бібліотек, які повинні бути узгоджені разом, відстежувати залежності 32-бітових електронних будівель важче. Наприклад, якщо вам потрібна 32-розрядна система media-libs/alsa-libв 32-бітній системі, ви просто встановите media-libs/alsa-lib, але в 64-бітній багатолібковій системі вам доведеться виявити, що app-emulation/emul-linux-soundlibsвстановлюється серед інших бібліотек 32-розрядна версія media-libs/alsa-lib. Крім того, Gentoo Dev, що створює один такий двійковий пакет, повинен виконувати роботу з з'ясування мультилібкових і побудови системних вигадок кожногоз включених бібліотек до пакету знімків, що ускладнює обслуговування. І, найголовніше, надання бінарних пакетів як єдиного офіційного варіанту використання мультиліб у 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це з'явилося в той час ABI_X86="32 64", він повинен бути встановлений за допомогою USE-прапорів abi_x86_32та abi_x86_64USE-прапорів. Якщо певному графічному пакету потрібна 32-бітна версія libX11, він може вказатиx11-libs/libX11[abi_x86_32]в її залежностях. Таким чином, якщо ви спробуєте вивести цей графічний пакет і libX11не встановили 32-бітні libs, portage відмовиться. multilib-build.eclassтакож є універсальним і сумісний з 32-бітовими системами: встановлення цього ж графічного пакета в 32-бітній системі завжди працюватиме, оскільки неможливо встановити libX11без встановлення його abi_x86_32useflag. Це вирішує проблему необхідності залежати від того, app-emulation/emul-linux-x86-xlibsколи буде багатомільтова система та безпосередньо від x11-libs/libX1132-бітової системи. Ми прокладаємо шлях до більш чистих і розумних залежностей між пакетами від багатолібкових систем. =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категорії таким чином: він нічого не встановлює, просто "вперед" залежність для існуючих ebuilds.

Ми бачили, як multilib-build.eclassвідкриває шлях до більш чистих залежностей від багатолібкових систем. Будь-який пакунок, який має ABI_X86параметри (те саме, що він має abi_x86_*useflags), встановив 32-бітну версію, якщо ви вказали USE=abi_x86_32/ ABI_X86=32. Як це працює (на високому концептуальному рівні)? Ви можете прочитати сам ebuild. В основному, ідея така ж, як python або ruby ​​ebuilds, які мають можливість встановити себе для декількох версій python та ruby ​​одночасно. Коли ebuild успадковується multilib-build.eclass, він переходить на ABI_X86 і робить кожен етап процесу розпакування, компіляції та установки для кожного запису в ABI_X86. Оскільки волок проходить через весь ебілд фаз , як src_unpack(), src_compile(), і src_install()(і інші) в порядку і тільки один раз,multilib-build.eclass(в даний час за допомогою multibuild.eclass) використовує створює каталог для кожного різного значення ABI_X86. Він розпакує копію джерел до кожного з цих каталогів. Звідти кожен із цих каталогів починає розходитися, оскільки кожен націлений на певний ABI. Каталог для ABI_X86=32буде ./configure --libdir=/usr/lib32запускатися з націлюванням на FLAGS на 32-бітне (наприклад, CFLAGS=-m32походить від envivar CFLAGS_x86 мультілібкового профілю (зауважте: профілі переносу здебільшого посилаються на 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або її детальний стан. На сьогоднішній день будівництво, що використовується, 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_32useflag іншого пакету (наприклад, 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-байтові вказівники. Це обмежує використання пам'яті до 4GiB і зменшує накладні витрати в більшості випадків, в той час як дозволяє використовувати всі 64-бітні інструкції.

В даний час ситуація справжнє пекло. Проблема, здається, полягає в тому, що багато пакунків начебто "напівмасковані" ... Я не знаю точної термінології, але здається, що деякі пакети мають ключове слово "~ amd64" з "abi_x86_32" прапором використання та "amd64" без що використовують прапор ... Результат полягає в тому, що під час мого оновлення я вмикаю "abi_x86_32", але з'являється, все ще встановлює пакети з ABI_X86 = "(64) (-32)", якщо я не додаю "~ amd64" для кожного такого пакета. І якщо вона витягується як залежність, а не виникла безпосередньо, немає жодної пропозиції автомасковим маскам написати цю зміну - emerge просто каже вам, що вона не може задовольнити залежність для цього пакету з необхідним прапором використання "abi_x86_32". Тому я повинен додати кожен пакет по одному до package.keywords з "~ amd64". Це багато ручної роботи ... І для якої версії пакета я повинен це робити? Я не можу сказати, чого я насправді хочу, а саме "для версій, де вона позначена" amd64 "без цього прапора". Я можу або помістити конкретну останню версію, яку я бачу зараз, і таким чином ускладнити її майбутні оновлення, або ввести всі версії, а потім, можливо, встановити версії, які не позначені стабільними навіть для 64-бітних ...

Посередньо пов’язана інформація: На сьогоднішній день повну систему робочого столу KDE в systemd можна скласти чисто мультілібковим способом (без емуляційних пакетів). Єдина проблема - це власний пакет nvidia-драйверів, але це можна вирішити, поки що відкриваємося з відкритим кодом.

Як почати точку (інші посилання включені там): https://forums.gentoo.org/viewtopic-t-985380-highlight-.html

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