Devo divulgar que tenho pouca experiência usando multilib-build.eclass-style multilib no Gentoo.
ABI_X86é uma USE_EXPANDvariável; configuração ABI_X86="32 64"ou USE="abi_x86_32 abi_x86_64"são equivalentes. A configuração padrão de ABI_X86, até o momento da redação deste documento (09/09/2013), para o default/linux/amd64/13.0perfil parece ser justa ABI_X86=64.
Essa variável controla o suporte multilib explícito nos ebuilds, que usam multilib-build.eclassuma maneira mais semelhante ao Gentoo de executar multilib do que o método original.
O método original que as bibliotecas de 32 bits seriam instaladas no Gentoo é através dos instantâneos binários nomeados app-emulation/emul-linux-*. Cada um desses pacotes binários de emulação contém um conjunto inteiro de bibliotecas de 32 bits compiladas por alguns desenvolvedores do Gentoo para você. Como cada um instala um pacote de bibliotecas que devem ser coordenadas, o rastreamento de dependências de ebuilds de apenas 32 bits é mais difícil. Por exemplo, se você precisa de 32 bits media-libs/alsa-libem um sistema de 32 bits, basta instalar media-libs/alsa-lib, mas em um sistema multilib de 64 bits, é necessário descobrir que app-emulation/emul-linux-soundlibsinstala, entre outras bibliotecas, a versão de 32 bits media-libs/alsa-lib. Além disso, o desenvolvedor do Gentoo que constrói um desses pacotes binários deve fazer o trabalho de descobrir as peculiaridades multilib e buildsystem de cadadas bibliotecas incluídas no pacote de instantâneos, dificultando a manutenção. E, mais importante, o fornecimento de pacotes binários como a única opção oficial para o uso de multilib no Gentoo vai contra o espírito do Gentoo. Você deve ter o direito de compilar tudo sozinho!
Ele multilib-build.eclassse afasta desse comportamento ajudando os ebuilds individuais a instalar as versões de 32 e 64 bits. Isso deve permitir, por exemplo, wineprecisar especificar apenas dependências diretamente nos pacotes de que precisa, em vez de precisar puxar os app-emulation/emul-linux-*pacotes. Como o ssuominen menciona no tópico do fórum que você referenciou :
= app-emulation / emul-linux-x86-xlibs-20130224-r1, que é um pacote vazio que não possui arquivos porque os arquivos agora vêm diretamente do x11-libs /
(Observe que -r1já foi renomeado para -r2) Eventualmente, app-emulation/emul-linux-x86-xlibsele próprio deve poder ser descartado, pois os pacotes somente de 32 bits dependem apropriadamente diretamente dos pacotes corretos x11-libs, pois, com multilib-build.eclassa ajuda de você, fornece as bibliotecas de 32 bits necessárias. É aqui que ABI_X86entra em jogo. Qualquer multilib-build.eclasspacote habilitado ganha pelo menos os novos USE abi_x86_32e abi_x86_64e provavelmente abi_x86_x32. Usando EAPI=2dependências de USE de estilo , os pacotes podem depender de versões de 32 bits de outros pacotes. Se x11-libs/libX11surgir enquanto ABI_X86="32 64", ele deve ser instalado com os sinalizadores USE abi_x86_32e os sinalizadores abi_x86_64USE definidos. Se um pacote gráfico específico precisar de uma versão de 32 bits libX11, ele poderá especificarx11-libs/libX11[abi_x86_32]em suas dependências. Dessa forma, se você tentar criar este pacote gráfico e libX11não tiver instalado bibliotecas de 32 bits, o portage recusará. multilib-build.eclasstambém é universal e é compatível com sistemas de 32 bits: a instalação desse mesmo pacote gráfico em um sistema de 32 bits sempre funcionará porque é impossível instalar libX11sem o seu abi_x86_32useflag definido. Isso resolve o problema de precisar depender de app-emulation/emul-linux-x86-xlibsum sistema multilib e diretamente x11-libs/libX11de um sistema somente de 32 bits. Estamos abrindo caminho para ter dependências entre pacotes mais limpas e sensíveis em sistemas multilib. =app-emulation/emul-linux-x86-xlibs-20130224-r2existe como um intermediário que permite que quaisquer pacotes antigos que costumavam depender e app-emulation/emul-linux-x86-xlibsque não sabem como depender diretamente, por exemplo, x11-libs/libX11[abi_x86_32]ainda funcionem.=app-emulation/emul-linux-x86-xlibs-20130224-r2garante que as mesmas bibliotecas de 32 bits existam /usr/lib32como se =app-emulation/emul-linux-x86-xlibs-20130224tivessem sido instaladas, mas funciona da maneira Gentoo, construindo essas bibliotecas de 32 bits por meio de suas dependências, em vez de fornecer um pacote binário. Ele se comporta da mesma maneira que os pacotes da virtualcategoria: não instala nada, apenas "encaminha" as dependências dos ebuilds existentes.
Vimos como multilib-build.eclassabre caminho para dependências mais limpas em sistemas multilib. Qualquer pacote que possua ABI_X86opções (o mesmo que dizer que possui abi_x86_*useflags) instalou uma versão de 32 bits, se você especificou USE=abi_x86_32/ ABI_X86=32. Como isso funciona (em um alto nível conceitual)? Você pode ler o ebuild em si. Basicamente, a idéia é a mesma que os ebuilds python ou ruby, que têm a opção de se instalarem para várias versões de python e ruby simultaneamente. Quando um ebuild herda multilib-build.eclass, ele executa um loop sobre ABI_X86 e executa cada etapa do processo de descompactação, compilação e instalação para cada entrada no ABI_X86. Como o portage passa por todas as fases do ebuild src_unpack(), como,, src_compile()e src_install()(e outros) em ordem e apenas uma vez, omultilib-build.eclass(atualmente, com a ajuda dos multibuild.eclass) usos cria um diretório para cada valor diferente de ABI_X86. Descompactará uma cópia das fontes para cada um desses diretórios. A partir daí, cada um desses diretórios começa a divergir conforme cada alvo de uma ABI específica. O diretório for ABI_X86=32será ./configure --libdir=/usr/lib32executado com o FLAGS direcionado para 32 bits (por exemplo, CFLAGS=-m32vem do CFLAGS_x86 envvar do perfil multilib (nota: os perfis do portage geralmente se referem a ABI_X86 = 32 como ABI = x86 e ABI_X86 = 64 como ABI = amd64)). Durante osrc_install()Na fase, todas as diferentes ABIs compiladas são instaladas umas sobre as outras, de modo que, quando qualquer arquivo possui versões de 32 e 64 bits, a ABI nativa vence (por exemplo, um ebuild instalando bibliotecas e um executável no PATH instalaria apenas um 64 executável no PATH, mas inclui bibliotecas de 32 e 64 bits). Para resumir: quando você definir ABI_X86="32 64"em make.conf, qualquer pacote que suporta multilib-build.eclasslevará cerca de duas vezes a quantidade de trabalho (eu não estou dizendo tempo ;-)) para compilar como está sendo construída uma vez para cada ABI e resulta em bibliotecas de 32 bits em /usr/lib32.
Não sei se ainda existe documentação oficial ABI_X86ou seu status detalhado. O uso do Ebuilds multilib-build.eclassparece instável, por enquanto. Você pode seguir as instruções no blog ao qual você vinculou para começar a experimentar e testar ABI_X86se entender a distinção entre app-emulation/emul-linux-x86-xlibs-20130224e a multilib de novo estilo app-emulation/emul-linux-x86-xlibs-20130224-r2. Mas, se você estiver de acordo com o pacote binário de estilo antigo, acho que ele app-emulation/emul-linux-x86-xlibs-20130224deve permanecer funcional. Você só precisará mudar para o -r2caso de usar qualquer pacote que dependa diretamente da abi_x86_32marca de uso de outro pacote (por exemplo, app-emulation/emul-linux-x86-xlibs-20130224e x1-libs/libX11[abi_x86_32]não possa coexistir porque provavelmente ambos instalam a mesma biblioteca /usr/lib32, a saber /usr/lib32/libX11.so.6). Uma rápidaolhe wine-1.7.0.ebuildsugere para mim que não precisa -r2.
app-emulation/emul-linux-x86e outros dependiam de suas contrapartes diretas . Foram necessárias muitas alterações de chave e de sinalização USE, mas eu tenho tudo para compilar e executar felizes juntos! :-D