Używanie ABI_X86 w Gentoo

Minęły miesiące, odkąd zaktualizowałem system Gentoo. I, jak możesz sobie wyobrazić, oznacza to, że jest wiele pakietów (i zmian w USE), które muszę omówić. Mój system to „amd64” (multilib), ale mam wiele ręcznie napisanych słów kluczowych pakietów z „~ amd64”.

W każdym razie w tej aktualizacji wciąż widzę flagi USE „ABI_X86”. Co to jest? To jest nowe. W „liście wiadomości eselect” nie ma nic na ten temat.

Znalazłem ten temat: http://forums.gentoo.org/viewtopic-t-953900-start-0.html . Wydawało się, że to pokazuje, jak go używać, ale czy są na to jakieś „prawdziwe” dokumenty? Co to robi? Co mam niby do zestawu „ABI_X86” do? Mam system multilib. Zakładam, że chcę „64”, ale czym są „32” i „x32”? Jestem zmieszany tym, co muszę tutaj zrobić.

Emerge dużo krzyczy na temat konfliktów automatów i wydaje się, że są one powiązane z „ABI_X86” (dokładnie zapominam o błędach, ale pamiętam, że jeden był zlib).

Czy są jakieś „oficjalne” dokumenty na temat tego, co to ABI_X86jest i jak z niego korzystać?

Z wątku, który podłączyłem, znalazłem tę stronę: http://kicherer.org/joomla/index.php/en/blog/liste/29-transition-of-emul-packages-to-true-multilib , ale chcę aby wiedzieć, co robię, zanim przejdę do słów kluczowych i zredaguję moje make.conf.

PS Mam większość pakietów „app-emulation / emul-linux-x86” (tych, które wydawały mi się wtedy potrzebne) w moim pliku „package.ke words”.

Muszę ujawnić, że mam niewielkie doświadczenie w korzystaniu z multilib-build.eclassmultilib -style w Gentoo.

ABI_X86jest USE_EXPANDzmienną; 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.0profilu wydaje się być sprawiedliwe ABI_X86=64.

Ta zmienna kontroluje jawną obsługę multilibów w ebuildach, które używają multilib-build.eclassbardziej 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-libw systemie 32-bitowym, po prostu instalujesz media-libs/alsa-lib, ale w 64-bitowym systemie multilib musisz odkryć, że app-emulation/emul-linux-soundlibsinstaluje, 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.eclassoddala się od tego problemu by pomagać indywidualnych ebuildy zainstalować obie wersje 32-bitowe i 64-bitowe. Powinno to pozwolić na przykład winena 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 -r1od tego czasu zmieniono jego nazwę -r2). W końcu app-emulation/emul-linux-x86-xlibssam powinien zostać usunięty, ponieważ pakiety tylko 32-bitowe odpowiednio zależą bezpośrednio od poprawnych pakietów, x11-libsponieważ z multilib-build.eclasspomocą zapewniają wymagane 32-bitowe biblioteki lib. Tutaj ABI_X86wchodzi w grę. Dowolny multilib-build.eclasspakiet z włączoną zyskuje przynajmniej nowe flagi USE abi_x86_32i abi_x86_64i prawdopodobnie abi_x86_x32. Korzystając z EAPI=2zależności w stylu USE , pakiety mogą zależeć od 32-bitowych wersji innych pakietów. Jeśli pojawi x11-libs/libX11się w tym czasie ABI_X86="32 64", należy go zainstalować z ustawionymi flagami USE abi_x86_32i flagami abi_x86_64USE. 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 libX11uruchomić ten pakiet graficzny i nie zainstalowałeś 32-bitowych bibliotek lib, portage odmówi. multilib-build.eclassjest 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ć libX11bez abi_x86_32ustawionej flagi useflag. To rozwiązuje problem konieczności app-emulation/emul-linux-x86-xlibspolegania na systemie multilib i bezpośrednio na x11-libs/libX11systemie 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-r2istnieje jako pośrednik, który pozwala, aby wszystkie stare pakiety, które kiedyś zależały, od app-emulation/emul-linux-x86-xlibsktó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-r2upewnia się, że te same 32-bitowe biblioteki istnieją /usr/lib32tak, jakby =app-emulation/emul-linux-x86-xlibs-20130224był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 virtualten 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.eclasstoruje drogę do czystszych zależności od systemów multilib. Każdy pakiet, który ma ABI_X86opcje (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=32będzie ./configure --libdir=/usr/lib32działał z FLAGS ukierunkowanymi na 32-bitowe (np. CFLAGS=-m32Pochodzi 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.confdowolny pakiet, który wspiera multilib-build.eclasszajmie 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_X86czy jej szczegółowy status. Korzystanie z ebuildów multilib-build.eclasswydaje 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_X86jeśli rozumiesz różnicę między app-emulation/emul-linux-x86-xlibs-20130224multilibem 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-20130224powinien on pozostać funkcjonalny. Musisz się do niego przenieść tylko -r2wtedy, gdy używasz dowolnego pakietu, który zależy bezpośrednio od abi_x86_32flagi użycia innego pakietu (na przykład app-emulation/emul-linux-x86-xlibs-20130224i 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.ebuildsugeruje mi, że nie potrzebuje -r2.

Istnieje 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.

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

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