在Gentoo中使用ABI_X86

自从我更新了Gentoo系统已经几个月了。而且，您可以想象，这意味着我需要检查很多程序包（以及USE更改）。我的系统是“ amd64”（multilib），但是我有很多来自“〜amd64”的手动关键字化软件包。

无论如何，在此更新中，我一直看到“ ABI_X86” USE标志。这是什么？这是新的。在“ eselect新闻列表”中什么也没有。

我找到了这个主题：http : //forums.gentoo.org/viewtopic-t-953900-start-0.html。这似乎表明了如何使用它，但是，对此是否有任何“真实”文档？它有什么作用？我应该将“ ABI_X86”设置为什么？我有一个multilib系统。我假设我想要“ 64”，但是“ 32”和“ x32”是什么？我对在这里需要做什么感到困惑。

Emerge对插槽冲突大喊大叫，它们似乎与“ ABI_X86”有关（我完全忘记了错误，但我记得其中一个是zlib）。

那么，关于什么ABI_X86是什么以及如何使用它，是否有任何“官方”文档？

在链接的线程中，我找到了以下页面：http : //kicherer.org/joomla/index.php/zh-CN/blog/liste/29-transition-of-emul-packages-to-true-multilib，但是我想要在关键字一堆东西并编辑我的内容之前要知道我在做什么make.conf。

PS我的“ package.keywords”文件中包含大多数“ app-emulation / emul-linux-x86”软件包（当时我似乎需要的软件包）。

我必须透露，我multilib-build.eclass在Gentoo中使用-style multilib的经验很少。

ABI_X86是一个USE_EXPAND变量；设置ABI_X86="32 64"或USE="abi_x86_32 abi_x86_64"等效。截至撰写本文时（2013-09-09），此default/linux/amd64/13.0配置文件的默认设置为ABI_X86 仅为just ABI_X86=64。

这个变量控制ebuilds中显式的multilib支持，使用multilib-build.eclass它比原始方法更像Gentoo那样做multilib。

将32位库安装在Gentoo中的原始方法是通过名为的二进制快照app-emulation/emul-linux-*。这些仿真二进制软件包中的每一个都包含由某些Gentoo开发人员为您编译的整套32位库。由于每个人都安装了一堆必须一起协调的库，因此跟踪仅32位ebuild的依赖关系会更加困难。例如，如果您需要media-libs/alsa-lib在32位系统上安装32位，则只需安装media-libs/alsa-lib，而在64位multilib系统上，则必须发现app-emulation/emul-linux-soundlibs安装了32位版本的media-libs/alsa-lib。同样，构建这样一个二进制包的Gentoo开发人员必须完成找出每个二进制包的multilib和buildsystem怪癖的工作。快照程序包中包含的库的数量，使维护工作更加困难。而且，最重要的是，提供二进制程序包作为在Gentoo中使用multilib的唯一选项正式选项，这与Gentoo的精神背道而驰。您应该有权自己编译所有内容！

在multilib-build.eclass帮助个人从ebuilds的这种行为远离移动安装两个 32位和64位版本。例如，这应该允许wine只需要直接针对所需的软件包指定依赖关系，而无需引入app-emulation/emul-linux-*软件包。正如ssuominen在您引用的论坛主题中提到的：

= app-emulation / emul-linux-x86-xlibs-20130224-r1，这是没有文件的空软件包，因为文件现在直接来自x11-libs /

（请注意，-r1此后已重命名为-r2）。最终，app-emulation/emul-linux-x86-xlibs它本身应该可以删除，因为仅32位的程序包适当地直接依赖于正确的程序包，x11-libs因为在multilib-build.eclass的帮助下，它提供了所需的32位库。这就是ABI_X86发挥作用的地方。multilib-build.eclass启用任何功能的软件包至少会获得新的USE标志abi_x86_32，abi_x86_64并且可能会获得abi_x86_x32。使用EAPI=2-style USE依赖项，软件包可以依赖于其他软件包的32位版本。如果x11-libs/libX11在时出现ABI_X86="32 64"，则应在安装时设置USE标志abi_x86_32和abi_x86_64USE标志。如果特定的图形软件包需要32位版本的libX11，则可以指定x11-libs/libX11[abi_x86_32]在其依赖项中。这样，如果您尝试出现此图形软件包libX11而未安装32位库，则移植将被拒绝。multilib-build.eclass也是通用的，并且与32位系统兼容：在32位系统上安装相同的图形包将始终有效，因为如果libX11未abi_x86_32设置useflag 则无法安装。这解决了需要依赖于app-emulation/emul-linux-x86-xlibs何时在multilib系统上以及直接依赖x11-libs/libX11于仅32位系统上的问题。我们为在多库系统上建立更清洁，更合理的软件包间依赖关系铺平了道路。=app-emulation/emul-linux-x86-xlibs-20130224-r2作为中介存在，它可以使以前依赖于app-emulation/emul-linux-x86-xlibs哪些不知道如何直接依赖的旧程序包x11-libs/libX11[abi_x86_32]继续工作。=app-emulation/emul-linux-x86-xlibs-20130224-r2确保确保存在/usr/lib32与=app-emulation/emul-linux-x86-xlibs-20130224安装时相同的32位库，但是通过Gentoo依赖关系构建这些32位库而不是提供二进制包，可以通过Gentoo方式进行。它的行为与类中的软件包非常相似virtual：它不会安装任何东西，只是“转发”现有ebuild的依赖项。

我们已经看到了如何multilib-build.eclass为更加依赖Multilib系统铺平道路。如果您指定了/ ，则任何具有ABI_X86选项的软件包（与说它具有abi_x86_*useflags一样）都已安装了自身的32位版本。这是如何工作的（在高概念级别上）？您可以阅读ebuild本身。基本上，这个想法与python或ruby ebuilds相同，后者可以选择同时为多个版本的python和ruby安装自己。当ebuild继承时，它将遍历ABI_X86并为ABI_X86中的每个条目执行解压缩，编译和安装过程的每个步骤。由于Portage经历都喜欢的ebuild阶段，和以（及其他），只有一次，USE=abi_x86_32ABI_X86=32multilib-build.eclasssrc_unpack()src_compile()src_install()multilib-build.eclass（当前在的帮助下multibuild.eclass），用法为ABI_X86的每个不同值创建一个目录。它将把源副本解压缩到每个目录中。从那里开始，这些目录中的每个目录都开始偏离，因为每个目录都针对特定的ABI。的目录ABI_X86=32将./configure --libdir=/usr/lib32与针对32位的FLAGS 一起运行（例如，CFLAGS=-m32来自multilib配置文件的CFLAGS_x86 envvar（注意：移植配置文件通常将ABI_X86 = 32称为ABI = x86，将ABI_X86 = 64称为ABI = amd64））。在此期间src_install()阶段，所有不同的已编译ABI都相互安装，这样，当任何文件同时具有32位和64位版本时，本机ABI胜出（例如，在PATH中同时安装库和可执行文件的ebuild只能安装64位可执行文件放入PATH，但同时包含32位和64位库）。综上所述：当你设置ABI_X86="32 64"的make.conf，任何包，它支持multilib-build.eclass将工作大约两倍量的（我不是说时间;-)）编译，因为它是正在兴建一次为每个ABI和结果在32位库中/usr/lib32。

我不知道是否有官方文件ABI_X86或其详细状态。目前，使用Ebuild的情况multilib-build.eclass似乎大多不稳定。ABI_X86如果您了解app-emulation/emul-linux-x86-xlibs-20130224和multistyle 的区别，则可以按照链接到博客的说明开始体验和测试app-emulation/emul-linux-x86-xlibs-20130224-r2。但是，如果您对旧式的二进制包没问题，我认为那app-emulation/emul-linux-x86-xlibs-20130224应该仍然可以使用。你只需要移动到-r2，如果你使用的任何包装，直接依赖于其他软件包的abi_x86_32useflag（例如，app-emulation/emul-linux-x86-xlibs-20130224并且x1-libs/libX11[abi_x86_32]不能共存，因为他们可能都安装相同的库/usr/lib32，即/usr/lib32/libX11.so.6）。一个快速看着wine-1.7.0.ebuild我觉得不需要-r2。

还有abi_x86_x32（与abi_x86_32不同）使用标记。这个是实验性的，旨在构建半64位应用程序。唯一的区别是它们具有4byte指针。这将内存使用限制为4GiB，并在大多数情况下减少了开销，同时允许使用所有64位指令。

目前情况真是糟透了。问题似乎是许多软件包都是“半掩蔽”的……我不知道确切的术语，但是似乎有些软件包的关键词是“〜amd64”，带有“ abi_x86_32”使用标志，而“ amd64”却没有使用标志的结果...结果是，在我更新期间，我启用了“ abi_x86_32”，但是除非每个这样的软件包添加“〜amd64”，否则新兴版仍会安装ABI_X86 =“（64）（-32）”的软件包。而且，如果将它作为依赖项拉出而不是直接出现，则没有提供自动unmask写入更改的提议-出现只是告诉您它无法通过所需的“ abi_x86_32”使用标志来满足该程序包的依赖项。因此，我必须使用“〜amd64”将每个软件包一个一个地添加到package.keywords中。那是很多手工工作... 我应该针对哪个软件包版本进行操作？我不能告诉我我真正想要的是什么，即“对于没有使用标记的标记为“ amd64”的版本”。我可以放入我现在看到的特定最新版本，从而使其将来的更新复杂化，或者放入所有版本，然后可能安装即使对于64位也未标记为稳定的版本...

间接相关的信息：到目前为止，可以纯multilib方式（没有仿真包）在systemd上编译完整的KDE桌面系统。现在唯一的问题是专有的nvidia-drivers软件包，但是现在可以通过使用开源的软件包来解决。

如何起点（此处包含其他链接）：https : //forums.gentoo.org/viewtopic-t-985380-highlight-.html

Gentoo Multilib移植状态https://wiki.gentoo.org/wiki/Multilib_porting_status