Devo rivelare che ho poca esperienza nell'uso di multilib-build.eclassmultilib in stile in Gentoo.
ABI_X86è una USE_EXPANDvariabile; impostazione ABI_X86="32 64"o USE="abi_x86_32 abi_x86_64"sono equivalenti. L'impostazione predefinita di ABI_X86, al momento della stesura di questo (2013-09-09), per il default/linux/amd64/13.0profilo sembra essere giusta ABI_X86=64.
Questa variabile controlla il supporto multilib esplicito negli ebuild che usano multilib-build.eclassun modo più simile a Gentoo di fare il multilib rispetto al metodo originale.
Il metodo originale secondo cui le librerie a 32 bit verrebbero installate in Gentoo è tramite le istantanee binarie denominate app-emulation/emul-linux-*. Ognuno di questi pacchetti binari di emulazione contiene un intero set di librerie a 32 bit compilate da alcuni sviluppatori Gentoo per te. Poiché ognuno installa un pacchetto di librerie che devono essere coordinate tra loro, è più difficile tenere traccia delle dipendenze di ebuild solo a 32 bit. Ad esempio, se hai bisogno di un 32 bit media-libs/alsa-libsu un sistema a 32 bit, devi solo installarlo media-libs/alsa-lib, ma su un sistema multilib a 64 bit, devi scoprire che app-emulation/emul-linux-soundlibsinstalla, tra le altre librerie, la versione a 32 bit di media-libs/alsa-lib. Inoltre, lo sviluppatore di Gentoo che costruisce uno di questi pacchetti binari deve fare il lavoro per capire le stranezze di multilib e buildsystem di ognidelle librerie incluse nel pacchetto snapshot, rendendo più difficile la manutenzione. E, soprattutto, fornire pacchetti binari come unica opzione ufficiale per l'uso del multilib in Gentoo va contro lo spirito di Gentoo. Dovresti avere il diritto di compilare tutto da solo!
Si multilib-build.eclassallontana da questo comportamento aiutando i singoli ebuild a installare entrambe le versioni a 32 e 64 bit. Ciò dovrebbe consentire, ad esempio, winesolo di specificare le dipendenze direttamente dai pacchetti di cui ha bisogno invece di dover inserire i app-emulation/emul-linux-*pacchetti. Come ssuominen menziona nella discussione del forum a cui hai fatto riferimento :
= emulazione app / emul-linux-x86-xlibs-20130224-r1 che è un pacchetto vuoto che non ha file perché i file ora provengono direttamente da x11-libs /
(Si noti che -r1da allora è stato rinominato -r2) Alla fine, app-emulation/emul-linux-x86-xlibsdovrebbe essere in grado di essere eliminato poiché i pacchetti a soli 32 bit dipendono appropriatamente direttamente dai pacchetti corretti in x11-libsquanto, con multilib-build.eclassl'aiuto, forniscono le lib necessarie a 32 bit. È qui che ABI_X86entra in gioco. Qualsiasi multilib-build.eclasspacchetto abilitato ottiene almeno i nuovi flag USE abi_x86_32e abi_x86_64e probabilmente abi_x86_x32. Utilizzando le EAPI=2dipendenze USE in stile , i pacchetti possono dipendere dalle versioni a 32 bit di altri pacchetti. Se x11-libs/libX11è emerso mentre ABI_X86="32 64", allora deve essere installato con flag USE abi_x86_32e flag abi_x86_64USE impostati. Se un determinato pacchetto grafico necessita di una versione a 32 bit di libX11, può specificarex11-libs/libX11[abi_x86_32]nelle sue dipendenze. In questo modo, se provi a emergere questo pacchetto grafico e libX11non hai installato librerie a 32 bit, il portage 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 da installare libX11senza che abi_x86_32sia impostato il flag use. Questo risolve il problema della necessità di dipendere da app-emulation/emul-linux-x86-xlibsun sistema multilib e direttamente x11-libs/libX11da un sistema a 32 bit. Stiamo aprendo la strada per avere dipendenze interpacchetto più pulite e sensibili dai sistemi multilib. =app-emulation/emul-linux-x86-xlibs-20130224-r2esiste come intermediario che consente a tutti i vecchi pacchetti che dipendevano da app-emulation/emul-linux-x86-xlibscui non sanno come dipendere direttamente, ad esempio x11-libs/libX11[abi_x86_32], di funzionare ancora.=app-emulation/emul-linux-x86-xlibs-20130224-r2si assicura che esistano le stesse librerie a 32 bit /usr/lib32come se =app-emulation/emul-linux-x86-xlibs-20130224fossero state installate, ma lo fa in modo Gentoo costruendo queste librerie a 32 bit attraverso le sue dipendenze anziché fornire un pacchetto binario. Si comporta in modo simile ai pacchetti della virtualcategoria in questo modo: non installa nulla, ma solo "inoltra" dipendenze per ebuild esistenti.
Abbiamo visto come multilib-build.eclassspianare la strada a dipendenze più pulite da sistemi multilib. Qualsiasi pacchetto che ha ABI_X86opzioni (come dire che ha abi_x86_*useflags) ha installato una versione a 32 bit di se stesso se è stato specificato USE=abi_x86_32/ ABI_X86=32. Come funziona (ad alto livello concettuale)? Puoi leggere l'ebuild stesso. Fondamentalmente, l'idea è la stessa degli ebuild di Python o Ruby che hanno la possibilità di installarsi contemporaneamente per più versioni di Python e Ruby. Quando un ebuild eredita multilib-build.eclass, passa su ABI_X86 ed esegue ogni fase del processo di decompressione, compilazione e installazione per ogni voce in ABI_X86. Poiché Portage passa attraverso tutte le fasi ebuild come src_unpack(), src_compile(), e src_install()(e altri) in ordine e solo una volta, ilmultilib-build.eclass(attualmente, con l'aiuto di multibuild.eclass) usa crea una directory per ogni diverso valore di ABI_X86. Disimballerà una copia dei sorgenti in ciascuna di queste directory. Da lì, ognuna di queste directory inizia a divergere man mano che ognuna si rivolge a un ABI particolare. La directory per ABI_X86=32verrà ./configure --libdir=/usr/lib32eseguita con il targeting FLAGS a 32 bit (ad esempio, CFLAGS=-m32proviene dal profilo multilib CFLAGS_x86 envvar (nota: i profili di portage si riferiscono principalmente ad ABI_X86 = 32 come ABI = x86 e ABI_X86 = 64 come ABI = amd64)). Durantesrc_install()fase, tutti i diversi ABI compilati sono installati l'uno sull'altro in modo tale che quando qualsiasi file ha entrambe le versioni a 32 e 64 bit, vince l'ABI nativo (ad esempio, un ebuild che installa entrambe le librerie e un eseguibile in PATH installerebbe solo un 64 -bit eseguibile in PATH ma include librerie a 32 e 64 bit). Per riassumere: quando si imposta ABI_X86="32 64"in make.conf, qualsiasi pacchetto che supporta multilib-build.eclassavrà circa il doppio della quantità di lavoro (non sto dicendo che il tempo ;-)) per la compilazione in quanto è in fase di costruzione una volta per ogni ABI e si traduce in librerie a 32 bit in /usr/lib32.
Non so se esiste ABI_X86ancora una documentazione ufficiale o il suo stato dettagliato. Gli ebuild che usano multilib-build.eclasssembrano essere per lo più instabili per ora. Puoi seguire le istruzioni sul blog a cui ti sei collegato per iniziare a sperimentare e testare ABI_X86se capisci la distinzione tra app-emulation/emul-linux-x86-xlibs-20130224e il nuovo stile multilib app-emulation/emul-linux-x86-xlibs-20130224-r2. Ma, se stai bene con il pacchetto binario vecchio stile, penso che app-emulation/emul-linux-x86-xlibs-20130224dovrebbe rimanere funzionale. Dovresti passare a solo -r2se usi un pacchetto che dipende direttamente dalla abi_x86_32useflag di un altro pacchetto (per esempio, app-emulation/emul-linux-x86-xlibs-20130224e x1-libs/libX11[abi_x86_32]non può coesistere perché probabilmente entrambi installano la stessa libreria /usr/lib32, vale a dire /usr/lib32/libX11.so.6). Un veloceguarda wine-1.7.0.ebuildmi suggerisce che non è necessario -r2.
app-emulation/emul-linux-x86dalle loro controparti dirette . Ci sono voluti un sacco di parole chiave e modifiche ai flag USE, ma ho avuto tutto da compilare ed eseguire felicemente insieme! MrGreen