Debo revelar que tengo poca experiencia en el uso de multilib-build.eclassmultilib de estilo en Gentoo.
ABI_X86es una USE_EXPANDvariable ajuste ABI_X86="32 64"o USE="abi_x86_32 abi_x86_64"son equivalentes. La configuración predeterminada de ABI_X86, a partir de este escrito (09/09/2013), para el default/linux/amd64/13.0perfil parece ser justa ABI_X86=64.
Esta variable controla el soporte multilib explícito en ebuilds que usan multilib-build.eclassuna forma más parecida a Gentoo de hacer multilib que el método original.
El método original para instalar las bibliotecas de 32 bits en Gentoo es a través de las instantáneas binarias nombradas app-emulation/emul-linux-*. Cada uno de estos paquetes binarios de emulación contiene un conjunto completo de bibliotecas de 32 bits compiladas por algunos desarrolladores de Gentoo para usted. Debido a que cada uno instala un paquete de bibliotecas que deben coordinarse juntas, el seguimiento de las dependencias de ebuilds de solo 32 bits es más difícil. Por ejemplo, si necesita un sistema de 32 bits media-libs/alsa-liben un sistema de 32 bits, simplemente instale media-libs/alsa-lib, pero en un sistema multilib de 64 bits, debe descubrir que app-emulation/emul-linux-soundlibsinstala, entre otras bibliotecas, la versión de 32 bits media-libs/alsa-lib. Además, el desarrollador de Gentoo que construye uno de estos paquetes binarios debe hacer el trabajo de descubrir las peculiaridades del sistema de equilibrio y compilación de cada unode las bibliotecas incluidas en el paquete de instantáneas, lo que dificulta el mantenimiento. Y, lo más importante, proporcionar paquetes binarios como la única opción oficial para usar multilib en Gentoo va en contra del espíritu de Gentoo. ¡Debe tener el derecho de compilar todo usted mismo!
Se multilib-build.eclassaleja de este comportamiento al ayudar a los ebuilds individuales a instalar versiones de 32 bits y de 64 bits. Esto debería permitir, por ejemplo, winesolo necesitar especificar dependencias directamente contra los paquetes que necesita en lugar de tener que extraer app-emulation/emul-linux-*paquetes. Como ssuominen menciona en el hilo del foro al que hizo referencia :
= aplicación-emulación / emul-linux-x86-xlibs-20130224-r1 que es un paquete vacío que no tiene archivos porque los archivos ahora vienen directamente de x11-libs /
(Tenga en cuenta que -r1desde entonces se le ha cambiado el nombre -r2). Eventualmente, app-emulation/emul-linux-x86-xlibsdebería poder descartarse ya que los paquetes de solo 32 bits dependen directamente de los paquetes correctos, ya x11-libsque, con multilib-build.eclassla ayuda, proporcionan las bibliotecas de 32 bits necesarias. Aquí es donde ABI_X86entra en juego. Cualquier multilib-build.eclasspaquete habilitado gana al menos los nuevos parámetros USE abi_x86_32y abi_x86_64y probablemente abi_x86_x32. Usando EAPI=2dependencias USE de estilo , los paquetes pueden depender de versiones de 32 bits de otros paquetes. Si x11-libs/libX11aparece mientras ABI_X86="32 64", se instalará con USE-flags abi_x86_32y abi_x86_64USE-flags set. Si un paquete gráfico particular necesita una versión de 32 bits libX11, puede especificarx11-libs/libX11[abi_x86_32]en sus dependencias De esta manera, si intenta crear este paquete gráfico y libX11no ha instalado libs de 32 bits, el portage se negará. multilib-build.eclasstambién es universal y es compatible con sistemas de 32 bits: la instalación de este mismo paquete gráfico en un sistema de 32 bits siempre funcionará porque es imposible instalarla libX11sin que abi_x86_32se configure su indicador de uso. Esto resuelve el problema de la necesidad de depender de app-emulation/emul-linux-x86-xlibscuándo está en un sistema multilib y directamente x11-libs/libX11en un sistema de solo 32 bits. Estamos allanando el camino para tener dependencias entre paquetes más limpias y sensatas en los sistemas multilib. =app-emulation/emul-linux-x86-xlibs-20130224-r2existe como un intermediario que permite que cualquier paquete antiguo que solía depender del app-emulation/emul-linux-x86-xlibscual no sabe depender directamente, por ejemplo, x11-libs/libX11[abi_x86_32]aún funcione.=app-emulation/emul-linux-x86-xlibs-20130224-r2se asegura de que existan las mismas bibliotecas de 32 bits /usr/lib32como si se =app-emulation/emul-linux-x86-xlibs-20130224hubieran instalado, pero lo hace a la manera de Gentoo al construir estas bibliotecas de 32 bits a través de sus dependencias en lugar de proporcionar un paquete binario. Se comporta de manera similar a los paquetes en la virtualcategoría de esta manera: no instala nada, solo depende de "reenviar" dependencias para ebuilds existentes.
Hemos visto cómo multilib-build.eclassallana el camino para dependencias más limpias en sistemas multilib. Cualquier paquete que tenga ABI_X86opciones (lo mismo que decir que tiene abi_x86_*banderas de uso) ha instalado una versión de 32 bits de sí mismo si ha especificado USE=abi_x86_32/ ABI_X86=32. ¿Cómo funciona esto (a un alto nivel conceptual)? Puedes leer el ebuild en sí. Básicamente, la idea es la misma que los ebuilds de python o ruby que tienen la opción de instalarse para múltiples versiones de python y ruby simultáneamente. Cuando un ebuild hereda multilib-build.eclass, recorre ABI_X86 y realiza cada paso del proceso de desempaquetado, compilación e instalación para cada entrada en ABI_X86. Desde Portage pasa a través de todas las fases ebuild como src_unpack(), src_compile(), y src_install()(y otros) en orden y sólo una vez, lamultilib-build.eclass(actualmente, con la ayuda de multibuild.eclass) utiliza crea un directorio para cada valor diferente de ABI_X86. Descomprimirá una copia de las fuentes en cada uno de estos directorios. A partir de ahí, cada uno de estos directorios comienza a divergir ya que cada uno apunta a un ABI particular. El directorio para ABI_X86=32se habrá ./configure --libdir=/usr/lib32ejecutado con FLAGS dirigidos a 32 bits (por ejemplo, CFLAGS=-m32proviene del perfil CFLAGS_x86 envvar del perfil multilib (nota: los perfiles de portage se refieren principalmente a ABI_X86 = 32 como ABI = x86 y ABI_X86 = 64 como ABI = amd64)). Durante elsrc_install()fase, todas las diferentes ABI compiladas se instalan unas sobre otras para que cuando los archivos tengan versiones de 32 bits y de 64 bits, la ABI nativa gane (por ejemplo, un ebuild que instala ambas bibliotecas y un ejecutable en PATH instalaría solo un 64 -bit ejecutable en PATH pero incluye tanto bibliotecas de 32 bits como de 64 bits). Para resumir: cuando se establece ABI_X86="32 64"en make.conf, cualquier paquete que los soportes multilib-build.eclassse llevará a aproximadamente el doble de la cantidad de trabajo (no estoy diciendo que el tiempo ;-)) para compilar, ya que se está construyendo una vez por cada ABI y los resultados en las bibliotecas de 32 bits en /usr/lib32.
No sé si todavía hay documentación oficial ABI_X86o su estado detallado. El uso de ebuilds multilib-build.eclassparece ser inestable por ahora. Puede seguir las instrucciones en el blog al que se vinculó para comenzar a experimentar y probar ABI_X86si comprende la distinción entre app-emulation/emul-linux-x86-xlibs-20130224el multilib de estilo nuevo app-emulation/emul-linux-x86-xlibs-20130224-r2. Pero, si está de acuerdo con el paquete binario de estilo antiguo, creo que app-emulation/emul-linux-x86-xlibs-20130224debería seguir siendo funcional. Solo necesitaría pasar -r2si usa un paquete que depende directamente de la abi_x86_32etiqueta de uso de otro paquete (por ejemplo, app-emulation/emul-linux-x86-xlibs-20130224y x1-libs/libX11[abi_x86_32]no puede coexistir porque probablemente ambos instalen la misma biblioteca /usr/lib32, es decir /usr/lib32/libX11.so.6). Un rápidomirar wine-1.7.0.ebuildme sugiere que no necesita -r2.
app-emulation/emul-linux-x86y otros dependían de sus contrapartes directas . Tomó muchas palabras clave y cambios en el indicador USE, ¡pero obtuve todo para compilar y ejecutar felices juntos! :-D