Muszę ujawnić, że mam niewielkie doświadczenie w korzystaniu z multilib-build.eclass
multilib -style w Gentoo.
ABI_X86
jest USE_EXPAND
zmienną; ustawienie ABI_X86="32 64"
lub USE="abi_x86_32 abi_x86_64"
są równoważne. Domyślne ustawienie ABI_X86, począwszy od tego pisania (2013-09-09), dla default/linux/amd64/13.0
profilu wydaje się być sprawiedliwe ABI_X86=64
.
Ta zmienna kontroluje jawną obsługę multilibów w ebuildach, które używają multilib-build.eclass
bardziej podobnego do Gentoo sposobu wykonywania multilibu niż oryginalna metoda.
Oryginalną metodą instalowania 32-bitowych bibliotek w Gentoo są binarne migawki o nazwie app-emulation/emul-linux-*
. Każdy z tych emulacyjnych pakietów binarnych zawiera cały zestaw 32-bitowych bibliotek skompilowanych przez jakiegoś dewelopera Gentoo. Ponieważ każda z nich instaluje pakiet bibliotek, które muszą być koordynowane razem, śledzenie zależności w ebuildach zawierających tylko 32 bity jest trudniejsze. Na przykład, jeśli potrzebujesz wersji 32-bitowej media-libs/alsa-lib
w systemie 32-bitowym, po prostu instalujesz media-libs/alsa-lib
, ale w 64-bitowym systemie multilib musisz odkryć, że app-emulation/emul-linux-soundlibs
instaluje, między innymi, wersję 32-bitową media-libs/alsa-lib
. Ponadto deweloper Gentoo budujący jeden taki pakiet binarny musi wykonać zadanie ustalenia dziwactwa multilib i buildsystem dla każdegobibliotek zawartych w pakiecie migawek, co utrudnia konserwację. Co najważniejsze, udostępnianie pakietów binarnych jako jedynej oficjalnej opcji używania multilib w Gentoo jest sprzeczne z duchem Gentoo. Powinieneś mieć prawo do samodzielnego skompilowania wszystkiego !
W multilib-build.eclass
oddala się od tego problemu by pomagać indywidualnych ebuildy zainstalować obie wersje 32-bitowe i 64-bitowe. Powinno to pozwolić na przykład wine
na określenie zależności bezpośrednio tylko od potrzebnych pakietów, zamiast konieczności pobierania app-emulation/emul-linux-*
pakietów. Jak wspomina ssuominen w wątku na forum, do którego się odwołujesz :
= app-emulation / emul-linux-x86-xlibs-20130224-r1, który jest pustym pakietem, który nie zawiera plików, ponieważ pliki pochodzą teraz bezpośrednio z x11-libs /
(Zauważ, że -r1
od tego czasu zmieniono jego nazwę -r2
). W końcu app-emulation/emul-linux-x86-xlibs
sam powinien zostać usunięty, ponieważ pakiety tylko 32-bitowe odpowiednio zależą bezpośrednio od poprawnych pakietów, x11-libs
ponieważ z multilib-build.eclass
pomocą zapewniają wymagane 32-bitowe biblioteki lib. Tutaj ABI_X86
wchodzi w grę. Dowolny multilib-build.eclass
pakiet z włączoną zyskuje przynajmniej nowe flagi USE abi_x86_32
i abi_x86_64
i prawdopodobnie abi_x86_x32
. Korzystając z EAPI=2
zależności w stylu USE , pakiety mogą zależeć od 32-bitowych wersji innych pakietów. Jeśli pojawi x11-libs/libX11
się w tym czasie ABI_X86="32 64"
, należy go zainstalować z ustawionymi flagami USE abi_x86_32
i flagami abi_x86_64
USE. Jeśli dany pakiet graficzny wymaga 32-bitowej wersji libX11
, może to określićx11-libs/libX11[abi_x86_32]
w jego zależnościach. W ten sposób, jeśli spróbujesz libX11
uruchomić ten pakiet graficzny i nie zainstalowałeś 32-bitowych bibliotek lib, portage odmówi. multilib-build.eclass
jest również uniwersalny i kompatybilny z systemami 32-bitowymi: instalacja tego samego pakietu graficznego w systemie 32-bitowym zawsze będzie działać, ponieważ nie można go zainstalować libX11
bez abi_x86_32
ustawionej flagi useflag. To rozwiązuje problem konieczności app-emulation/emul-linux-x86-xlibs
polegania na systemie multilib i bezpośrednio na x11-libs/libX11
systemie tylko 32-bitowym. Torujemy drogę do uzyskania czystszych i rozsądniejszych zależności między pakietami w systemach multilib. =app-emulation/emul-linux-x86-xlibs-20130224-r2
istnieje jako pośrednik, który pozwala, aby wszystkie stare pakiety, które kiedyś zależały, od app-emulation/emul-linux-x86-xlibs
których nie wiem, jak bezpośrednio polegać, na przykład, x11-libs/libX11[abi_x86_32]
nadal działają.=app-emulation/emul-linux-x86-xlibs-20130224-r2
upewnia się, że te same 32-bitowe biblioteki istnieją /usr/lib32
tak, jakby =app-emulation/emul-linux-x86-xlibs-20130224
były zainstalowane, ale robi to w Gentoo, budując te 32-bitowe biblioteki poprzez swoje zależności, a nie dostarczając pakiet binarny. W virtual
ten sposób zachowuje się bardzo podobnie do pakietów w tej kategorii: nie instaluje niczego, tylko „przekazuje” zależności dla istniejących ebuildów.
Widzieliśmy, jak multilib-build.eclass
toruje drogę do czystszych zależności od systemów multilib. Każdy pakiet, który ma ABI_X86
opcje (to samo, co mówienie, że ma abi_x86_*
flagi useflag), zainstalował 32-bitową wersję, jeśli podałeś USE=abi_x86_32
/ ABI_X86=32
. Jak to działa (na wysokim poziomie koncepcyjnym)? Możesz przeczytać sam ebuild. Zasadniczo pomysł jest taki sam, jak ebuildy Pythona lub Ruby, które mają opcję zainstalowania się dla wielu wersji Pythona i Ruby jednocześnie. Kiedy ebuild dziedziczy multilib-build.eclass
, zapętla się nad ABI_X86 i wykonuje każdy krok procesu rozpakowywania, kompilacji i instalacji dla każdego wpisu w ABI_X86. Ponieważ Portage przechodzi przez wszystkie fazy ebuild podobnych src_unpack()
, src_compile()
oraz src_install()
(i innych) w porządku i tylko raz,multilib-build.eclass
(obecnie przy pomocy multibuild.eclass
) używa tworzy katalog dla każdej innej wartości ABI_X86. Rozpakuje kopię źródeł do każdego z tych katalogów. Od tego momentu każdy z tych katalogów zaczyna się rozchodzić, ponieważ każdy celuje w określony ABI. Katalog dla ABI_X86=32
będzie ./configure --libdir=/usr/lib32
działał z FLAGS ukierunkowanymi na 32-bitowe (np. CFLAGS=-m32
Pochodzi z envvar CFLAGS_x86 profilu multilib (uwaga: profile portage najczęściej określają ABI_X86 = 32 jako ABI = x86 i ABI_X86 = 64 jako ABI = amd64)). Podczassrc_install()
faza, wszystkie różne skompilowane ABI są instalowane nad sobą tak, że gdy jakiekolwiek pliki mają zarówno wersje 32-bitowe, jak i 64-bitowe, rodzime ABI wygrywa (np. ebuild instalujący obie biblioteki i plik wykonywalny w PATH instaluje tylko 64 -bitowy plik wykonywalny do PATH, ale zawiera zarówno biblioteki 32-bitowe, jak i 64-bitowe). Podsumowując: po ustawieniu ABI_X86="32 64"
na make.conf
dowolny pakiet, który wspiera multilib-build.eclass
zajmie mniej więcej dwukrotnie większą ilość pracy (nie mówię, czas ;-)) do kompilacji, ponieważ jest budowany raz dla każdego ABI i wyniki w bibliotekach 32-bit /usr/lib32
.
Nie wiem, czy jest jeszcze oficjalna dokumentacja ABI_X86
czy jej szczegółowy status. Korzystanie z ebuildów multilib-build.eclass
wydaje się na razie w większości niestabilne. Możesz postępować zgodnie z instrukcjami na blogu, do którego prowadzisz link, aby zacząć doświadczać i testować, ABI_X86
jeśli rozumiesz różnicę między app-emulation/emul-linux-x86-xlibs-20130224
multilibem w nowym stylu app-emulation/emul-linux-x86-xlibs-20130224-r2
. Ale jeśli nie masz nic przeciwko pakietowi binarnemu w starym stylu, myślę, że app-emulation/emul-linux-x86-xlibs-20130224
powinien on pozostać funkcjonalny. Musisz się do niego przenieść tylko -r2
wtedy, gdy używasz dowolnego pakietu, który zależy bezpośrednio od abi_x86_32
flagi użycia innego pakietu (na przykład app-emulation/emul-linux-x86-xlibs-20130224
i x1-libs/libX11[abi_x86_32]
nie może współistnieć, ponieważ prawdopodobnie oba instalują tę samą bibliotekę /usr/lib32
, mianowicie /usr/lib32/libX11.so.6
). szybkiespojrzenie na wine-1.7.0.ebuild
sugeruje mi, że nie potrzebuje -r2
.
app-emulation/emul-linux-x86
innych, a inne od bezpośrednich odpowiedników. Wymagało to wielu zmian słów kluczowych i flag USE, ale udało mi się wszystko skompilować i działać razem! :-DIstnieje również flaga użycia abi_x86_x32 (to nie to samo co abi_x86_32). Ten jest eksperymentalny i ma na celu budowanie aplikacji pół 64-bitowych. Jedyną różnicą jest to, że mają wskaźniki 4-bajtowe. Ogranicza to użycie pamięci do 4GiB i zmniejsza obciążenie w większości przypadków, a jednocześnie pozwala korzystać ze wszystkich instrukcji 64-bitowych.
źródło
Obecnie sytuacja jest naprawdę piekła. Problemem wydaje się być to, że wiele pakietów jest w pewnym sensie „pół-maskowanych” ... Nie znam dokładnej terminologii, ale wydaje się, że niektóre pakiety mają słowa kluczowe „~ amd64” z „abi_x86_32” flagą użycia i „amd64” bez które używają flagi ... W rezultacie podczas mojej aktualizacji włączam „abi_x86_32”, ale emerge nadal instaluje pakiety z ABI_X86 = „(64) (-32)”, chyba że dodam „~ amd64” dla każdego takiego pakietu. A jeśli zostanie on pobrany jako zależność, a nie pojawi się bezpośrednio, nie ma oferty automatycznego maskowania-zapisu tej zmiany - emerge informuje tylko, że nie może zaspokoić zależności dla tego pakietu za pomocą wymaganej flagi „abi_x86_32”. Więc muszę dodawać każdy pakiet jeden po drugim do package.ke words z „~ amd64”. To dużo pracy ręcznej ... I dla jakiej wersji pakietu powinienem to zrobić? Nie mogę powiedzieć, czego tak naprawdę chcę, a mianowicie „dla wersji, w których jest oznaczony„ amd64 ”bez tej flagi użycia”. Mogę umieścić konkretną najnowszą wersję, którą teraz widzę, a tym samym skomplikować jej przyszłe aktualizacje, lub zainstalować wszystkie wersje, a następnie ewentualnie zainstalować wersje, które nie są oznaczone jako stabilne nawet dla wersji 64-bitowej ...
źródło
my-category/package
wpackage.keywords
Portage automatycznie interpretuje to jako przyjęcie dowolnego~amd64
(zakładając, żeARCH=amd64
). Można dostać tylko zachowanie, które opisują (pasujące wersje bez z~amd64
flagą) jeśli powiesz coś takiegomy-category/package **
.Informacje pośrednio powiązane: Na dzień dzisiejszy kompletny system pulpitu KDE na systemd może być skompilowany w czysty sposób na wiele warstw (bez pakietów emulacji). Jedynym problemem jest teraz zastrzeżony pakiet sterowników NVIDIA, ale można to rozwiązać, przechodząc do wersji open source.
Jak rozpocząć (inne linki tam zawarte): https://forums.gentoo.org/viewtopic-t-985380-highlight-.html
Status przenoszenia Gentoo Multilib https://wiki.gentoo.org/wiki/Multilib_porting_status
źródło