我的问题相当概念化。我注意到同一架构有不同的软件包，比如x86-64，但适用于不同的操作系统。例如，RPM为相同的x86-64架构为Fedora和OpenSUSE提供了不同的软件包：http://www.rpmfind.net/linux/rpm2html/search.php?query=wget - 更不用说YUM和APT（针对Ubuntu）提供的不同软件包，全部用于x86-64。
我的理解是一个包包含适用于给定CPU体系结构的二进制指令，因此只要CPU具有该体系结构，它就应该能够本地执行这些指令。那么为什么针对不同操作系统为相同架构构建的软件包会有所不同？
考虑到不同的Linux发行版：
除了针对不同的库版本编译（如Hadi所描述），包装本身和默认配置文件可以是不同的。也许一个发行版想要/etc/wget.conf，而另一个可能想要/etc/default/wget.conf，或者那些文件有不同的内容。 （如果wget专门有一个全局配置文件，我会忘记;有些软件包肯定会这样做，而不仅仅是像Exim或Apache这样的服务器。）
或者不同的发行版可以启用/禁用不同的编译时选项集。 （传统上在./configure --enable-foo --disable-bar之前用make -j4 && make install设置）。
对于wget，选择可能包括要编译的TLS库（OpenSSL与gnutls），而不仅仅是哪个版本。
所以ABI（库版本）很重要，但是还有其他原因可以解释为什么每个发行版都有自己的包。
完全不同的操作系统，如Linux与Windows与OS X，具有不同的可执行文件格式。 ELF vs. PE vs. Mach-O。所有这三种格式都包含x86-64机器代码，但元数据不同。 （OS差异意味着您希望机器代码执行不同的操作。
例如，可以使用int open(const char *pathname, int flags, mode_t mode);系统调用在Linux或OS X（或任何POSIX OS）上打开文件。因此相同的源代码适用于这两个平台，尽管它仍然可以编译为不同的机器代码，或者实际上在这种情况下非常相似的机器代码可以调用围绕系统调用的libc包装器（OS X and Linux use the same function calling convention），但具有不同的符号名称。 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传统（真实或克隆实现），因此低级文件的内容类似。
这些包包含需要运行特定Application Binary Interface（ABI）的本机二进制文件。 CPU架构只是ABI的一部分。不同的Linux发行版有不同的ABI，因此相同的二进制文件可能不是compatible。这就是为什么相同的架构有不同的包，但不同的操作系统。 Linux Standard Base项目旨在标准化Linux发行版的ABI，以便更容易构建可移植的软件包。