为什么相同架构有不同的包，但操作系统不同？答案

【问题标题】：Why are there different packages for the same architecture, but different OSes?为什么相同架构有不同的包，但操作系统不同？
【发布时间】：2018-03-21 23:18:34
【问题描述】：

我的问题是相当概念性的。我注意到同一架构有不同的软件包，比如 x86-64，但适用于不同的操作系统。例如，RPM 为同一个 x86-64 架构的 Fedora 和 OpenSUSE 提供了不同的软件包：http://www.rpmfind.net/linux/rpm2html/search.php?query=wget - 更不用说 YUM 和 APT（对于 Ubuntu）提供的不同软件包，所有这些都适用于 x86-64。

我的理解是，一个包包含适用于给定 CPU 架构的二进制指令，因此只要 CPU 属于该架构，它就应该能够本地执行这些指令。那么为什么为相同架构构建的软件包在不同操作系统中会有所不同呢？

【问题讨论】：

什么意思？对于每个版本的操作系统，每个支持的架构都需要一个包。 Possible duplicate.
对...我的问题是：为什么有一个用于 Fedora 的 x86-64 包，还有另一个用于 OpenSUSE 的 x86-64 包，还有另一个用于 Ubuntu 的 x86-64 包，等等。这些包有什么区别？

标签： operating-system cpu-architecture package-managers abi

【解决方案1】：

仅考虑不同的 Linux 发行版：

除了针对不同的库版本进行编译（如 Hadi 所述）之外，打包本身和默认配置文件可能不同。也许一个发行版想要/etc/wget.conf，而另一个可能想要/etc/default/wget.conf，或者这些文件有不同的内容。（我忘记了 wget 是否专门有一个全局配置文件；有些包肯定有，而不仅仅是像 Exim 或 Apache 这样的服务器。）

或者不同的发行版可以启用/禁用不同的编译时选项集。（传统上在make -j4 && make install之前设置./configure --enable-foo --disable-bar）。

对于wget，选择可能包括要针对哪个 TLS 库进行编译（OpenSSL 与 gnutls），而不仅仅是哪个版本。

所以 ABI（库版本）很重要，但每个发行版都有自己的软件包还有其他原因。

完全不同的操作系统，例如 Linux、Windows 和 OS X，具有不同的可执行文件格式。 ELF vs. PE vs. Mach-O。这三种格式都包含 x86-64 机器代码，但元数据不同。（操作系统差异意味着您希望机器代码执行不同的操作。

例如，可以使用int open(const char *pathname, int flags, mode_t mode); 系统调用在 Linux 或 OS X（或任何 POSIX 操作系统）上打开文件。所以相同的源代码适用于这两个平台，尽管它仍然可以编译成不同的机器代码，或者实际上在这种情况下非常相似的机器代码来调用围绕系统调用 (OS X and Linux use the same function calling convention) 的 libc 包装器，但使用不同的符号姓名。 OS X 将编译为对 _open 的调用，但 Linux 不会在符号名称前面加上下划线，因此动态链接器符号名称将为 open。

open 的模式常数可能不同。例如也许 OS X 将 O_RDWR 定义为 4，但也许 Linux 将其定义为 2。这将是 ABI 的区别：相同的源代码编译为不同的机器代码，程序和库就什么意思达成一致。

但是Windows 不是 POSIX 系统。打开文件的WinAPI函数是HFILE WINAPI OpenFile(LPCSTR lpFileName, LPOFSTRUCT lpReOpenBuff, UINT uStyle);

如果您想做比打开/关闭文件更近的事情，尤其是绘制 GUI，平台之间的事情甚至更不相似，您将使用不同的库。（或者一个跨平台的 GUI 库会在不同的平台上使用不同的后端）。

OS X 和 Linux 都具有 Unix 遗产（真实的或作为克隆实现），所以低级文件的东西是相似的。

【讨论】：

感谢 Peter Cordes 的详细解答！您说“ABI（库版本）”，但我认为库位置（依赖库所在/安装的位置 - 也许这与您关于 .conf 文件位置的观点相同）和操作系统系统调用（可能是一个操作系统的系统调用与其他的略有不同）也是 ABI 的一部分，这也可能是包（对于相同架构）不同的原因，对吧？
@flow2k：是的，更广泛地说，其中一些是 ABI 的一部分，就像 Hadi 在 LSB 和 FHS 项目中提到的那样，试图将事物标准化，以便更容易移植 3rd-party 软件（尽管 3rd-派对的东西会安装在/opt 或/usr/local，而不是/usr)。不过，在哪里安装自己的文件并不是真正的 ABI 事情，而是打包标准的事情。发行包不需要在自定义位置查找库，但是，/etc/ld.so.conf 已经列出了 /usr/lib 以及其他任何发行包放置库的地方，其他包可以针对这些库进行构建。
顺便说一句，我说的是一种 ABI，其中程序和库中的机器代码就 struct 的大小、它有哪些成员以及编译时间的值达成一致常数。向struct 添加新成员需要重新编译任何按值复制它的代码，或者具有该结构的数组的代码。或者程序和库必须同意的对编译时常量的任何更改。优秀的库维护者在进行此类更改时会升级 ABI 版本；这就是为什么 x264 最多 libx264.so.155；他们以改变 ABI 的方式不断改进它。
例如在x264.h 中从 x264 ABI 版本 149 到 150 的提升得到了the commit that added AVX-512 支持，其中changed a struct type defined in cpu.h to have const char *name instead of const char name[16]; 构建脚本使用X264_BUILD 作为so 名称
感谢 Peter Cordes 提供的所有这些详细信息！还要感谢 Hadi Brais。

【解决方案2】：

这些软件包包含需要特定 Application Binary Interface (ABI) 才能运行的本机二进制文件。 CPU 架构只是 ABI 的一部分。不同的 Linux 发行版具有不同的 ABI，因此相同的二进制文件可能不是 compatible。这就是为什么对于相同的架构有不同的包，但不同的操作系统。 Linux Standard Base 项目旨在标准化 Linux 发行版的 ABI，以便更轻松地构建可移植包。

【讨论】：