是什么使OSX程序无法在Linux上运行？

40

我知道OSX和Linux之间存在许多差异，但是是什么使它们如此完全不同，从而使它们从根本上不兼容呢？

— 法尔玛里
source

5

那么，为什么您希望OSX程序在Linux上可运行？那么这两个特定的OS会如何使您在问题中提及它们，但是没有其他任何同样不能运行OSX程序的OS呢？

— wrosecrans 2010年

6

这基本上是我的问题。OSX在unix内核上运行。我想知道与其他Unix / Linux相比，它有什么特别之处

— Falmarri 2010年

6

只有Mac机器才能看到的二进制文件中有个秘密的小苹果

— bobobobo

通常，不同的操作系统无法运行彼此的二进制文件。这就是为什么将软件作为源tarball分发的做法在Unix上长大的原因。MacOS和Linux在这方面都不是特别的：如果任何一个都可以运行对方的二进制文件，那将是特别的事情。回复wrosecrans的评论而被更广泛支持的评论完全没法要点。：/

— Peter Cordes

56

整个ABI是不同的，而不仅仅是sepp2k提到的二进制格式（Mach-O与ELF）。

例如，虽然Linux和达尔文/ XNU（OS X的内核）同时使用sc的PowerPC和int 0x80/ sysenter/ syscallx86上的系统调用入口，有没有共同点更多的从那里。

达尔文将负的系统调用号定向到Mach微内核，并将正的系统调用号定向到BSD整体内核—请参阅xnu / osfmk / mach / syscall_sw.h和xnu / bsd / kern / syscalls.master。Linux的系统调用号因体系结构而异-请参阅linux / arch / powerpc / include / asm / unistd.h，linux / arch / x86 / include / asm / unistd_32.h和linux / arch / x86 / include / asm / unistd_64.h -但都是非负的。所以很明显的系统调用号，系统调用的参数，甚至它的系统调用存在不同。

标准的C运行时库也不同。达尔文主要继承了FreeBSD的libc，而Linux通常使用glibc（但还有其他选择，例如eglibc和Dietlibc以及uclibc和Bionic）。

更不用说整个图形堆栈是不同的。忽略整个Cocoa Objective-C库，OS X上的GUI程序通过Mach端口与WindowServer对话，而在Linux上，GUI程序通常使用X11协议通过UNIX域套接字与X Server对话。当然，也有例外; 您可以在Darwin上运行X，也可以在Linux上绕过X，但是OS X应用程序绝对不会使用X。

像葡萄酒一样，如果有人将作品投入

为Mach-O实现二进制加载程序
捕获每个XNU系统调用并将其转换为适当的Linux系统调用
根据需要编写OS X库（如CoreFoundation）的替代品
根据需要编写OS X服务（例如WindowServer）的替代品

然后可以在Linux上“本地”运行OS X程序。几年前，Kyle Moffet在第一个项目上做了一些工作，为Linux 创建了原型binfmt_mach-o，但是它从未完成，而且我还没有其他类似的项目。

（从理论上讲，这是完全有可能的，并且已经做了很多类似的工作；除了Wine之外，Linux本身还支持运行其他UNIX（例如HP-UX和Tru64）的二进制文件，Glendix项目旨在使Plan 9兼容。 Linux。）

有人已经在努力为Linux实现Mach-O二进制加载器和API转换器！

shinh / maloader-GitHub采用类似Wine的方法来加载二进制文件并捕获/转换用户空间中的所有库调用。它完全忽略了系统调用和所有与图形相关的库，但是足以使许多控制台程序正常工作。

Darling建立在maloader的基础上，添加了库和其他支持的运行时位。

— 短暂的
source

比起拥有自己的任何内核代码，使用binfmt_misc进行新的尝试的可能性更大，不是吗？

— SamB 2010年

@SamB：是否曾经尝试在chroot中设置binfmt_misc处理程序？我认为处理内核中其他类似UNIX的系统的二进制格式是相当合理的。

— ephemient 2010年

1

我的问题是；如果您已经使OS X二进制文件可以在Linux上运行，那么为什么需要重写OS X库和服务？那时它们在Linux上不会运行不变吗？这仅仅是法律问题吗？

— Hubro

20

为什么OSX应用程序不能在Linux上本地运行：

首先，OSX使用与Linux不同的二进制格式，因此Linux无法执行针对OSX编译的二进制文件（无法执行针对Windows或BSD编译的二进制文件的方式）。

其次，如果您正在谈论GUI应用程序，则苹果公司的GUI工具包Cocoa a）仅可用于OSX，b）不能在X11之上运行。

为什么没有适合OSX应用程序的葡萄酒：

在葡萄酒甚至不能使用一半之前，必须完成许多工作。由于对OSX的需求不多，因此尚无人在此项目上投入相同的精力。

— sepp2k
source

您知道，我什至没有意识到OSX / unix没有使用相同的二进制格式。您是否有指向更多信息的链接？

— Falmarri 2010年

Falmarri：OSX使用Mach-O格式，Linux使用ELF。

— sepp2k 2010年

1

@Falmarri并非所有的UNIX都使用相同的二进制格式，即使几乎所有现代的UNIX也都使用ELF，但通常仍然不能从一个UNIX在另一个UNIX上运行二进制文件。哎呀，我不认为FreeBSD甚至可以保证您可以在8.x上运行7.x的程序，反之亦然，而1.0的Linux程序仍应在2.6.x上运行。

— ephemient

5

OS X应用程序不能在Linux上运行的最重要原因是因为这些OS使用了不同的系统调用。

先前的一些答案提到了库，但通常不是这样-Core Foundation主要由Apple以CFLite的名称开源，并且可以方便地移植到任何平台（iTunes的Windows版本实际上位于Core Foundation的Windows端口之上，并且一些编译器调整，您可以在Linux发行版上使用clang直接制作CFLite），并且还进行了开放源代码的工作，以将Objective-C环境（主要是Foundation和AppKit）移植到Linux，最著名的是GNUstep，这是OpenStep的GNU实现。早于苹果公司的Cocoa（该公司成立时仍是NeXT Computer。）

如果确定某人，他们可以设计一个加载器，该加载器将捕获每个Mach-O系统调用并将其转换为相应的Linux系统调用，并通过适当的ABI转换将这些开放源代码库“对等”动态链接到二进制文件。

仅作为参考，如果您可以获得Mach-O应用程序的源代码，则可以考虑移植它，并且结果可能非常简单。例如，剥离了几行（非关键）CF代码之后，可以直接重新编译与OS X 10.6捆绑在一起的TextEdit应用程序，以针对GNUstep进行链接，从而可以在Linux下立即使用（更不用说GNUstep附带的TextEdit实际上是一个直接从NeXTSTEP（也是OS X的前身）重新编译TextEdit应用程序，甚至保留其“©1995 NeXT”标签）。TextEdit受BSD许可。

— 陈
source

1

2012年12月8日，新项目-达令（Darling）已启动。

http://www.darlinghq.org/

— 塔塔卡兹卡
source