Mac OS X 和 Linux 之间的二进制兼容性

Question

振作起来，这个问题可能会显得幼稚和/或愚蠢，因为我对类 Unix 系统的内部工作以及一般的编程比较陌生。

准备好？好的！我会经历大约 3 个可笑的水平，随着我的进行而增加。

---

我们有两个具有相似硬件的系统（主要是处理器，让我们说一个标准的英特尔核心 2 双核）。

一个正在运行（在此处插入您的 linux 发行版：此后将使用 Ubuntu），另一个正在运行，比如说 Mac OS X。

编译一个等效的程序，让我们这样说：

int main()
{
    int cat = 33;
    int dog = 5*cat;
    return dog;
}

代码非常简单，因为我还不想考虑共享库的含义。

在各自的系统上编译时。输出之间的主要区别不是 ELF 与 Mach-O 的问题吗？如果要剥离格式的每个二进制文件，留下一个平面二进制文件，反汇编的机器指令是不是一样？（根据编译器的习惯/倾向，可能会有一些差异）。

1.)如果要开发一个程序来重新打包从我们的 Ubuntu 系统生成的平面二进制文件，以 Mach-O 格式，它会在 Mac OS X 系统中运行吗？那么，如果只有上面假设程序的编译后的二进制文件，并且有这个用于重新打包平面二进制文件的神秘工具，那么简单的程序是否能够在 Mac OS X 系统上运行？

---

现在让我们更进一步。

我们现在有一个带有源代码的程序，例如：

#include <stdio.h>
int main()
{
    printf("I like tortoises, but not porpoises");
    return 0;
}

2.)假设这个程序被编译并静态链接，我们的神奇程序是否仍然能够以 Mach-O 格式重新打包原始二进制文件并使其在 mac os X 上运行？看到它不需要依赖任何其他二进制文件，（在这种情况下，mac系统不会有）

---

现在是最后一关；

3.)如果我们使用这个假设的程序将​​所有必需的共享库转换为 Mach-O 格式，然后使用动态链接编译上面的程序会怎样。程序还能成功运行吗？

现在应该是这样，显然每一步荒谬都依赖于先前的基础，甚至有意义。所以如果第一根柱子被摧毁，我怀疑剩下的层会有多少优点。

我什至不会考虑使用带有 GUI 的程序来考虑这一点。窗口系统可能是另一个令人头疼的问题。在这个阶段我只考虑命令行程序。

现在，我请全世界纠正我，并告诉我我荒谬的思维方式的所有错误。

Answer 1

你忘记了一件至关重要的事情，即你的程序必须与操作系统交互才能做任何有趣的事情。

Linux 和 OS X 之间的约定不同，因此相同的二进制文件不能按原样运行，而实际上没有一大块操作系统相关代码能够与之交互。许多这些东西是通过库提供的，然后您需要链接到库中，这意味着您的程序需要可链接，并且两个系统之间的链接也不同。

就这样一直持续下去。表面上听着做同样的事情，实际细节上却大不相同。

Answer 2

如果有人想花足够的时间来实现它，这是可行的。该达林项目正在尝试这一点，但截至发稿时，它在一个相当原始的状态。

之前在其他平台上也成功过：

• Solaris 和 UnixWare 包含一个名为的帮助程序lxrun，其工作方式类似于sudo：您将可执行文件名称和参数传递给帮助程序，它会动态修复问题，以便可执行文件可以与操作系统对话。该官方网站（下降，存档链接）表示，它bitrotted。

• Linux 的内核曾经有一个叫做iBCS的功能，它可以做相反的事情，只是它不需要帮助程序，因为内核直接识别“外部”二进制文件。它在内核 2.3 开发系列中年久失修，很可能是因为 2.4 出现后，小型 Unix 服务器之战基本上结束了。

• FreeBSD 的内核可以配置为识别 Linux 二进制文件并像本地运行一样运行它们。此功能似乎比上述两个功能更好。

  OpenBSD 和 NetBSD 具有相似的特性。

OS X 中有很多 FreeBSD，所以移植它的 Linux 支持可能很简单。