Verwendung von ABI_X86 in Gentoo

Es ist Monate her, seit ich mein Gentoo-System aktualisiert habe. Und wie Sie sich vorstellen können, bedeutet dies, dass ich eine Menge Pakete (und USE-Änderungen) durchgehen muss. Mein System ist "amd64" (multilib), aber ich habe eine Menge manuell verschlüsselter Pakete von "~ amd64".

Jedenfalls sehe ich in diesem Update immer wieder die USE-Flags "ABI_X86". Was ist das? Das ist neu. Es gibt nichts in der "Nachrichtenliste auswählen" darüber.

Ich fand dieses Thema: http://forums.gentoo.org/viewtopic-t-953900-start-0.html . Das schien zu zeigen, wie man es benutzt, aber gibt es dafür "echte" Dokumente? Was tut es? Auf was soll ich "ABI_X86" setzen? Ich habe ein Multilib-System. Ich nehme an, ich möchte "64", aber was sind dann "32" und "x32"? Ich bin verwirrt darüber, was ich hier tun muss.

Emerge schreit viel über Slot-Konflikte und sie scheinen mit "ABI_X86" zu zusammenhängen (ich vergesse die Fehler genau, aber ich erinnere mich, dass einer zlib war).

Gibt es also "offizielle" Dokumente darüber, was ABI_X86ist und wie man es benutzt?

Aus dem Thread, den ich verlinkt habe, habe ich diese Seite gefunden: http://kicherer.org/joomla/index.php/en/blog/liste/29-transition-of-emul-packages-to-true-multilib , aber ich möchte um zu wissen, was ich tue, bevor ich ein paar Keywords eingebe und meine Videos bearbeite make.conf.

PS Ich habe die meisten "app-emulation / emul-linux-x86" -Pakete (die ich zu der Zeit anscheinend brauchte) in meiner "package.keywords" -Datei.

Ich muss offenlegen, dass ich wenig Erfahrung mit multilib-build.eclass-style multilib in Gentoo habe.

ABI_X86ist eine USE_EXPANDVariable; Einstellung ABI_X86="32 64"oder USE="abi_x86_32 abi_x86_64"sind gleichwertig. Die Standardeinstellung von ABI_X86 für das default/linux/amd64/13.0Profil ist zum jetzigen Zeitpunkt (09.09.2013) gerecht ABI_X86=64.

Diese Variable steuert die explizite Multilib-Unterstützung in Ebuilds, multilib-build.eclassdie eine Gentoo-ähnliche Methode zur Ausführung von Multilib verwenden als die ursprüngliche Methode.

Die ursprüngliche Methode, mit der 32-Bit-Bibliotheken in Gentoo installiert werden, erfolgt über die genannten binären Snapshots app-emulation/emul-linux-*. Jedes dieser Emulations-Binärpakete enthält eine ganze Reihe von 32-Bit-Bibliotheken, die von einigen Gentoo-Entwicklern für Sie kompiliert wurden. Da jeder ein Paket von Bibliotheken installiert, die zusammen koordiniert werden müssen, ist es schwieriger, die Abhängigkeiten von nur 32-Bit-Ebuilds zu verfolgen. Zum Beispiel, wenn Sie einen 32-Bit benötigen media-libs/alsa-libauf einem 32-Bit - System installieren Sie nur media-libs/alsa-lib, aber auf einem 64-Bit - multilib System, müssen Sie entdecken , dass app-emulation/emul-linux-soundlibsInstallationen unter anderen Bibliotheken, die 32-Bit - Version von media-libs/alsa-lib. Außerdem muss der Gentoo-Entwickler, der ein solches Binärpaket erstellt, die Multilib- und Buildsystem-Macken jedes einzelnen herausfindender im Snapshot-Paket enthaltenen Bibliotheken, was die Wartung erschwert. Und vor allem widerspricht die Bereitstellung von Binärpaketen als einzige offizielle Option für die Verwendung von Multilib in Gentoo dem Geist von Gentoo. Sie sollten das Recht haben, alles selbst zu kompilieren !

Die multilib-build.eclassZüge von diesem Verhalten weg von einzelnen ebuilds helfen installieren sowohl 32-Bit- als auch 64-Bit - Versionen. Dies sollte beispielsweise ermöglichen, dass winenur Abhängigkeiten direkt zu den benötigten Paketen angegeben werden müssen, anstatt dass app-emulation/emul-linux-*Pakete eingezogen werden müssen. Als ssuominen in dem Forum-Thread erwähnt, auf den Sie verwiesen haben :

= app-emulation / emul-linux-x86-xlibs-20130224-r1 ist ein leeres Paket ohne Dateien, da die Dateien jetzt direkt aus der x11-libs stammen /

(Hinweis, -r1der inzwischen in umbenannt wurde -r2) Schließlich app-emulation/emul-linux-x86-xlibssollte es möglich sein , selbst als reine 32-Bit-Pakete zu löschen, die angemessenerweise direkt von den richtigen Paketen abhängen x11-libs, um mit ihrer multilib-build.eclassHilfe die erforderlichen 32-Bit-Bibliotheken bereitzustellen. Hier ABI_X86kommt es ins Spiel. Jedes multilib-build.eclassaktivierte Paket erhält mindestens die neuen USE-Flags abi_x86_32und abi_x86_64und wahrscheinlich abi_x86_x32. Bei Verwendung von EAPI=2-style USE-Abhängigkeiten können Pakete von 32-Bit-Versionen anderer Pakete abhängen. Wenn dies x11-libs/libX11auftritt ABI_X86="32 64", muss es mit gesetzten USE-Flags abi_x86_32und abi_x86_64USE-Flags installiert werden . Wenn ein bestimmtes Grafikpaket eine 32-Bit-Version von benötigt libX11, kann dies angegeben werdenx11-libs/libX11[abi_x86_32]in seinen Abhängigkeiten. Auf diese Weise libX11lehnt portage ab , wenn Sie versuchen, dieses Grafikpaket zu erstellen, und keine 32-Bit-Bibliotheken installiert haben. multilib-build.eclassist ebenfalls universell und kompatibel mit 32-Bit-Systemen: Die Installation desselben Grafikpakets auf einem 32-Bit-System funktioniert immer, da die Installation libX11ohne abi_x86_32gesetztes Useflag nicht möglich ist. Dies löst das Problem, dass Sie sich app-emulation/emul-linux-x86-xlibsauf ein Multilib-System und direkt auf ein reines x11-libs/libX1132-Bit-System verlassen müssen. Wir ebnen den Weg zu saubereren und vernünftigen Abhängigkeiten zwischen Paketen von Multilib-Systemen. =app-emulation/emul-linux-x86-xlibs-20130224-r2existiert als Vermittler, der es alten Paketen ermöglicht, von app-emulation/emul-linux-x86-xlibsdenen abhängig zu sein , die nicht wissen, wie sie direkt abhängen sollen, um beispielsweise x11-libs/libX11[abi_x86_32]noch zu funktionieren.=app-emulation/emul-linux-x86-xlibs-20130224-r2stellt sicher, dass die gleichen 32-Bit-Bibliotheken vorhanden sind, /usr/lib32als ob =app-emulation/emul-linux-x86-xlibs-20130224sie installiert worden wären , tut dies jedoch auf Gentoo-Weise, indem diese 32-Bit-Bibliotheken über ihre Abhängigkeiten erstellt werden, anstatt ein Binärpaket bereitzustellen. Es verhält sich ähnlich wie Pakete in der virtualKategorie: Es installiert nichts, sondern "leitet" Abhängigkeiten für vorhandene Ebuilds weiter.

Wir haben gesehen, wie wir multilib-build.eclassden Weg für sauberere Abhängigkeiten von Multilib-Systemen ebnen. Jedes Paket, das ABI_X86Optionen hat (genau wie gesagt, es hat abi_x86_*useflags), hat eine 32-Bit-Version von sich selbst installiert, wenn Sie USE=abi_x86_32/ angegeben haben ABI_X86=32. Wie funktioniert das (auf hohem konzeptionellen Niveau)? Sie können das Ebuild selbst lesen. Grundsätzlich ist die Idee dieselbe wie bei Python- oder Ruby-Ebuilds, die die Option haben, sich für mehrere Versionen von Python und Ruby gleichzeitig zu installieren. Wenn ein Ebuild erbt multilib-build.eclass, durchläuft es eine Schleife über ABI_X86 und führt jeden Schritt des Entpackens, Kompilierens und Installationsvorgangs für jeden Eintrag in ABI_X86 aus. Da Portage alle Ebuild-Phasen wie src_unpack(), src_compile()und src_install()(und andere) nacheinander durchläuft und nur einmal diemultilib-build.eclassmultibuild.eclassErstellt (derzeit mit Hilfe von ) ein Verzeichnis für jeden unterschiedlichen Wert von ABI_X86. Es wird eine Kopie der Quellen in jedes dieser Verzeichnisse entpackt. Ab diesem Zeitpunkt beginnt jedes dieser Verzeichnisse zu divergieren, da jedes auf ein bestimmtes ABI abzielt. Das Verzeichnis für ABI_X86=32haben wird ./configure --libdir=/usr/lib32laufen mit FLAGS 32-Bit - Targeting (zB CFLAGS=-m32kommt aus dem CFLAGS_x86 envvar der multilib Profils (Anmerkung: portage Profile meist auf ABI_X86 beziehen = 32 als ABI = x86 und ABI_X86 = 64 als ABI = amd64)). Während dersrc_install()In dieser Phase werden alle verschiedenen kompilierten ABIs übereinander installiert, sodass bei Dateien mit 32-Bit- und 64-Bit-Versionen das native ABI gewinnt (z. B. würde ein Ebuild, das beide Bibliotheken installiert, und eine ausführbare Datei in PATH nur 64 installieren) -bit kann in PATH ausgeführt werden, enthält jedoch sowohl 32-Bit- als auch 64-Bit-Bibliotheken. Um es zusammenzufassen: Wenn Sie festgelegt ABI_X86="32 64"in make.confjede Verpackung , die Träger multilib-build.eclassnehmen etwa die doppelte Menge an Arbeit (ich bin nicht an der Zeit zu sagen ;-)) zu kompilieren , wie es für jeden ABI und die Ergebnisse einmal gebaut wird in 32-Bit - Bibliotheken in /usr/lib32.

Ich weiß nicht, ob es für ABI_X86noch offizielle Unterlagen gibt oder welchen detaillierten Status sie haben. Die Verwendung von Ebuilds multilib-build.eclassscheint vorerst weitgehend instabil zu sein. Befolgen Sie die Anweisungen in dem Blog, auf das Sie verlinkt haben, um Erfahrungen zu sammeln und zu testen, ABI_X86ob Sie den Unterschied zwischen app-emulation/emul-linux-x86-xlibs-20130224und der Multilib im neuen Stil verstehen app-emulation/emul-linux-x86-xlibs-20130224-r2. Aber wenn Sie mit dem Binärpaket im alten Stil einverstanden sind, sollte dies meiner Meinung app-emulation/emul-linux-x86-xlibs-20130224nach weiterhin funktionieren. Sie müssten nur umziehen, -r2wenn Sie ein Paket verwenden, das direkt vom abi_x86_32Useflag eines anderen Pakets abhängt (z. B. app-emulation/emul-linux-x86-xlibs-20130224und x1-libs/libX11[abi_x86_32]nicht koexistieren kann, weil wahrscheinlich beide dieselbe Bibliothek installieren /usr/lib32, nämlich /usr/lib32/libX11.so.6). Ein schnellesschau wine-1.7.0.ebuildmal, schlägt mir vor, dass es nicht nötig ist -r2.

Es gibt auch abi_x86_x32 (es ist nicht dasselbe wie abi_x86_32) use flag. Dieser ist experimentell und soll Semi-64-Bit-Anwendungen erstellen. Der einzige Unterschied besteht darin, dass sie 4-Byte-Zeiger haben. Dies begrenzt die Speichernutzung auf 4 GB und reduziert in den meisten Fällen den Overhead, während alle 64-Bit-Anweisungen verwendet werden können.

Momentan ist die Situation die Hölle. Das Problem scheint zu sein, dass viele Pakete irgendwie "halb maskiert" sind ... Ich kenne die exakte Terminologie nicht, aber es scheint, dass einige Pakete mit dem Schlüsselwort "~ amd64" mit "abi_x86_32" und "amd64" ohne "use flag" versehen sind that use flag ... Das Ergebnis ist, dass ich während meiner Aktualisierung "abi_x86_32" aktiviere, aber emerge weiterhin Pakete mit ABI_X86 = "(64) (-32)" installiert, es sei denn, ich füge "~ amd64" für jedes dieser Pakete hinzu. Und wenn es als eine Abhängigkeit gezogen wird, anstatt direkt aufgetaucht zu sein, gibt es kein Angebot, diese Änderung automatisch zu schreiben - emerge sagt nur, dass es die Abhängigkeit für dieses Paket nicht mit dem benötigten "abi_x86_32" -Verwendungsflag erfüllen kann. Also muss ich jedes Paket einzeln zu package.keywords mit "~ amd64" hinzufügen. Das ist viel Handarbeit ... Und für welche Paketversion soll ich das machen? Ich kann es nicht sagen, was ich eigentlich will, nämlich "für Versionen, bei denen es als" amd64 "ohne das use flag" markiert ist. Ich kann entweder die aktuellste Version einfügen, die ich jetzt sehe, und so die zukünftigen Updates erschweren, oder ich kann alle Versionen einfügen und dann möglicherweise Versionen installieren, die selbst für 64-Bit-Versionen nicht als stabil markiert sind.

Indirekt verwandte Informationen: Ab heute kann das vollständige KDE-Desktopsystem auf systemd in reiner Multilib-Form kompiliert werden (keine Emulationspakete). Das einzige Problem ist jetzt das proprietäre nvidia-drivers-Paket. Dieses Problem kann jedoch gelöst werden, indem Sie zunächst auf Open Source umsteigen.

Wie man anfängt (andere Links sind dort enthalten): https://forums.gentoo.org/viewtopic-t-985380-highlight-.html

Gentoo Multilib-Portierungsstatus https://wiki.gentoo.org/wiki/Multilib_porting_status