Skip to content

Utilizzare ABI_X86 in Gentoo

La guida o il codice che troverai in questo post è la soluzione più semplice ed efficace che abbiamo trovato a questa preoccupazione o dilemma.

Soluzione:

Devo rivelare che ho poca esperienza nell'uso di multilib-build.eclass-style multilib in Gentoo.

ABI_X86 è un USE_EXPAND variabilee; impostazione ABI_X86="32 64" o USE="abi_x86_32 abi_x86_64" sono equivalenti. L'impostazione predefinita di ABI_X86, al momento in cui scriviamo (2013-09-09), per il parametro default/linux/amd64/13.0 sembra essere solo ABI_X86=64.

Questa variabile controlla il supporto multilib esplicito negli ebuild che usano il profilo multilib-build.eclass che è un modo più simile a Gentoo di fare il multilib rispetto al metodo originale.

Il metodo originale con cui le librerie a 32 bit vengono installate in Gentoo è tramite gli snapshot binari denominati app-emulation/emul-linux-*. Ognuno di questi pacchetti binari di emulazione contiene un intero insieme di librerie a 32 bit compilate da qualche sviluppatore di Gentoo per voi. Poiché ognuno di essi installa un gruppo di librerie che devono essere coordinate insieme, è più difficile tracciare le dipendenze degli ebuild a 32 bit. Per esempio, se si ha bisogno di una libreria a 32 bit media-libs/alsa-lib su un sistema a 32 bit, si installa semplicemente media-libs/alsa-lib, ma su un sistema multilib a 64 bit, si deve scoprire che app-emulation/emul-linux-soundlibs installa, tra le altre librerie, la versione a 32 bit di media-libs/alsa-lib. Inoltre, lo sviluppatore di Gentoo che costruisce un pacchetto binario di questo tipo deve fare il lavoro di capire le stranezze di multilib e del sistema di compilazione di ogni delle librerie incluse nel pacchetto snapshot, rendendo più difficile la manutenzione. E, soprattutto, fornire pacchetti binari come unica opzione ufficiale per l'uso di multilib in Gentoo va contro lo spirito di Gentoo. Dovreste avere il diritto di compilare tutto da soli!

Il multilib-build.eclass si allontana da questo comportamento aiutando i singoli ebuild a installare entrambi versioni a 32 e 64 bit. Questo dovrebbe permettere, per esempio, wine di dover specificare le dipendenze direttamente dai pacchetti di cui ha bisogno, invece di dover inserire i dati di app-emulation/emul-linux-* pacchetti. Come menzionato da ssuominen nel thread del forum a cui si fa riferimento:

=app-emulation/emul-linux-x86-xlibs-20130224-r1 che è un pacchetto vuoto che non ha file perché i file provengono ora direttamente da x11-libs/

(Si noti che -r1 è stato rinominato in -r2) Alla fine, app-emulation/emul-linux-x86-xlibs dovrebbe poter essere eliminato, in quanto i pacchetti a 32 bit dipendono direttamente dai pacchetti corretti in x11-libs che, con multilib-build.eclassforniscono le librerie a 32 bit necessarie. Questo è il punto in cui ABI_X86 entra in gioco. Qualsiasi multilib-build.eclass-abilitato guadagna almeno i nuovi flag USE abi_x86_32 e abi_x86_64 e probabilmente abi_x86_x32. Utilizzando EAPI=2-style USE dependencies, i pacchetti possono dipendere da versioni a 32 bit di altri pacchetti. Se x11-libs/libX11 è emerso mentre ABI_X86="32 64", allora deve essere installato con i flag USE abi_x86_32 e abi_x86_64 USE-flags. Se un particolare pacchetto grafico necessita di una versione a 32 bit di libX11può specificare x11-libs/libX11[abi_x86_32] nelle sue dipendenze. In questo modo, se si cerca di emergere da questo pacchetto grafico e da libX11 non ha installato le librerie a 32 bit, portage si rifiuterà. multilib-build.eclass è anche universale ed è compatibile con i sistemi a 32 bit: l'installazione di questo stesso pacchetto grafico su un sistema a 32 bit funzionerà sempre, perché è impossibile installare libX11 senza il suo abi_x86_32 senza che il suo useflag sia impostato. Questo risolve il problema della necessità di dipendere da app-emulation/emul-linux-x86-xlibs quando si è in un sistema multilib e direttamente da x11-libs/libX11 su un sistema a 32 bit. Stiamo aprendo la strada per avere dipendenze interpacchetti più pulite e sensate sui sistemi multilib. =app-emulation/emul-linux-x86-xlibs-20130224-r2 esiste come intermediario che permette a qualsiasi vecchio pacchetto che dipendeva da app-emulation/emul-linux-x86-xlibs che non sanno come dipendere direttamente da, per esempio, x11-libs/libX11[abi_x86_32],x11-libs/libX11[abi_x86_32], di continuare a funzionare. =app-emulation/emul-linux-x86-xlibs-20130224-r2 si assicura che le stesse librerie a 32 bit esistano in /usr/lib32 come se =app-emulation/emul-linux-x86-xlibs-20130224 ma lo fa alla maniera di Gentoo, costruendo queste librerie a 32 bit attraverso le sue dipendenze invece di fornire un pacchetto binario. Si comporta come i pacchetti della classe virtual non installa nulla, ma "inoltra" le dipendenze per gli ebuild esistenti.

Abbiamo visto come multilib-build.eclass apre la strada a dipendenze più pulite sui sistemi multilib. Qualsiasi pacchetto che abbia ABI_X86 (la stessa cosa che dire che ha abi_x86_* useflags) ha installato una versione a 32 bit di se stesso se si è specificato USE=abi_x86_32/ABI_X86=32. Come funziona (a un livello concettuale elevato)? Si può leggere l'ebuild stesso. Fondamentalmente, l'idea è la stessa degli ebuild di python o ruby, che hanno la possibilità di installarsi per più versioni di python e ruby contemporaneamente. Quando un ebuild eredita multilib-build.eclassfa un loop su ABI_X86 ed esegue ogni passo del processo di spacchettamento, compilazione e installazione per ogni voce di ABI_X86. Dal momento che portage attraversa tutte le fasi di ebuild come src_unpack(), src_compile()e src_install() (e altre) in ordine e solo una volta, l'opzione multilib-build.eclass (attualmente, con l'aiuto del multibuild.eclass) crea una directory per ogni diverso valore di ABI_X86. In ognuna di queste directory viene scompattata una copia dei sorgenti. Da qui, ognuna di queste directory inizia a divergere, poiché ognuna si rivolge a una particolare ABI. La cartella per ABI_X86=32 avrà ./configure --libdir=/usr/lib32 eseguito con FLAGS mirati a 32 bit (ad esempio, CFLAGS=-m32 proviene dalla envvar CFLAGS_x86 del profilo multilib (nota: i profili portage si riferiscono per lo più a ABI_X86=32 come ABI=x86 e ABI_X86=64 come ABI=amd64). Durante la fase di src_install() tutti i diversi ABI compilati vengono installati l'uno sull'altro, in modo che quando un file ha versioni sia a 32 che a 64 bit, l'ABI nativo vince (per esempio, un ebuild che installa sia le librerie che un eseguibile nel PATH installerebbe solo un eseguibile a 64 bit nel PATH, ma includerebbe sia le librerie a 32 che quelle a 64 bit). Per riassumere: quando si imposta ABI_X86="32 64" in make.conf, qualsiasi pacchetto che supporti multilib-build.eclass richiederà all'incirca il doppio del lavoro (non dico del tempo ;-)) per la compilazione, in quanto viene compilato una volta per ogni ABI e risulta in librerie a 32 bit in /usr/lib32.

Non so se esista una documentazione ufficiale per il codice ABI_X86 o il suo stato dettagliato. Le compilazioni che utilizzano multilib-build.eclass sembrano essere per lo più instabili per ora. Si possono seguire le istruzioni del blog a cui ci si è collegati per iniziare a sperimentare e testare ABI_X86 se si comprende la distinzione tra app-emulation/emul-linux-x86-xlibs-20130224 e il nuovo stile multilib app-emulation/emul-linux-x86-xlibs-20130224-r2. Ma, se si è a posto con il pacchetto binario vecchio stile, penso che app-emulation/emul-linux-x86-xlibs-20130224 dovrebbe rimanere funzionale. Si dovrebbe solo passare a -r2 se si usa un pacchetto che dipende direttamente da un altro pacchetto abi_x86_32 useflag (per esempio, app-emulation/emul-linux-x86-xlibs-20130224 e x1-libs/libX11[abi_x86_32] non possono coesistere perché probabilmente entrambi installano la stessa libreria in /usr/lib32e cioè /usr/lib32/libX11.so.6). A veloce occhiata a wine-1.7.0.ebuild mi suggerisce che non ha bisogno di -r2.

Esiste anche il flag d'uso abi_x86_x32 (non è lo stesso di abi_x86_32). Questo è sperimentale e destinato a costruire applicazioni semi-64bit. L'unica differenza è che hanno puntatori a 4byte. Questo limita l'uso della memoria a 4GiB e riduce l'overhead nella maggior parte dei casi, consentendo di utilizzare tutte le istruzioni a 64bit.

Apprezziamo che desideri aggiungere valore alle nostre informazioni collaborando con la tua anzianità nei rapporti.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.