Usando ABI_X86 en Gentoo

Han pasado meses desde que actualicé mi sistema Gentoo. Y, como puede imaginar, esto significa que hay muchos paquetes (y cambios de USO) que necesito revisar. Mi sistema es "amd64" (multilib), pero tengo muchos paquetes con palabras clave de "~ amd64".

De todos modos, en esta actualización, sigo viendo indicadores USE "ABI_X86". ¿Que es esto? Esto es nuevo. No hay nada en la "lista de noticias de eselect" al respecto.

Encontré este tema: http://forums.gentoo.org/viewtopic-t-953900-start-0.html . Eso parecía mostrar cómo usarlo, pero, ¿hay algún documento "real" para esto? ¿Qué hace? ¿Qué se supone que debo configurar "ABI_X86"? Tengo un sistema multilib. Supongo que quiero "64", pero ¿qué son "32" y "x32"? Estoy confundido con lo que necesito hacer aquí.

Emerge está gritando mucho sobre conflictos de tragamonedas, y parecen estar relacionados con "ABI_X86" (Olvidé los errores exactamente, pero recuerdo que uno era zlib).

Entonces, ¿hay algún documento "oficial" sobre qué ABI_X86es y cómo usarlo?

Desde el hilo que enlacé, encontré esta página: http://kicherer.org/joomla/index.php/en/blog/liste/29-transition-of-emul-packages-to-true-multilib , pero quiero para saber lo que estoy haciendo antes de ir a la palabra clave un montón de cosas y editar mi make.conf.

PD: Tengo la mayoría de los paquetes "app-emulation / emul-linux-x86" (los que parecía necesitar en ese momento) en mi archivo "package.keywords".

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.

También hay abi_x86_x32 (no es lo mismo que abi_x86_32) use flag. Este es experimental y está destinado a construir aplicaciones de semi-64 bits. La única diferencia es que tienen punteros de 4bytes. Esto limita el uso de memoria a 4GiB y reduce la sobrecarga en la mayoría de los casos, al tiempo que permite usar todas las instrucciones de 64 bits.

Actualmente la situación es un verdadero infierno. El problema parece ser que muchos paquetes están más o menos "enmascarados" ... No sé la terminología exacta, pero parece que algunos paquetes tienen palabras clave "~ amd64" con "abi_x86_32" use flag y "amd64" sin que usan la bandera ... El resultado es que, durante mi actualización, habilito "abi_x86_32" pero emerge aún instala paquetes con ABI_X86 = "(64) (-32)" a menos que agregue "~ amd64" por cada paquete. Y si se extrae como una dependencia en lugar de emerger directamente, no hay oferta para autounmask-escribir ese cambio - emerge solo le dice que no puede satisfacer la dependencia para ese paquete con el indicador de uso "abi_x86_32" necesario. Así que tengo que agregar cada paquete uno por uno a package.keywords con "~ amd64". Eso es mucho trabajo manual ... ¿Y para qué versión de paquete debo hacerlo? No puedo decirle lo que realmente quiero, a saber, "para las versiones donde está marcado" amd64 "sin ese indicador de uso". Puedo poner la última versión específica que veo ahora y así complicar sus futuras actualizaciones, o poner todas las versiones y luego posiblemente instalar versiones que no están marcadas como estables incluso para 64 bits ...

Información indirectamente relacionada: a partir de hoy, el sistema completo de escritorio KDE en systemd se puede compilar de manera puramente equilibrada (sin paquetes de emulación). El único problema ahora es el paquete propietario de nvidia-drivers, pero esto se puede resolver con uno de código abierto por ahora.

Cómo comenzar el punto (otros enlaces incluidos allí): https://forums.gentoo.org/viewtopic-t-985380-highlight-.html

Estado de transferencia de Gentoo Multilib https://wiki.gentoo.org/wiki/Multilib_porting_status