Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

I know there are many differences between OSX and Linux, but what makes them so totally different, that makes them fundamentally incompatible?

share|improve this question
Well, why would you expect OSX programs to be runnable on Linux? What about these two specific OS's makes you mention them in the question, but not any other OS that also can't run OSX programs? – wrosecrans Dec 17 '10 at 5:03
That's basically my question. OSX runs on a unix kernel. I was wondering what about it makes it special compared to other unix/linuxes – Falmarri Dec 20 '10 at 1:57
There are secret little apples inside the binaries that only Mac machines can see  – bobobobo Jan 8 '14 at 16:52

4 Answers 4

up vote 41 down vote accepted

The whole ABI is different, not just the binary format (Mach-O versus ELF) as sepp2k mentioned.

For example, while both Linux and Darwin/XNU (the kernel of OS X) use sc on PowerPC and int 0x80/sysenter/syscall on x86 for syscall entry, there's not much more in common from there on.

Darwin directs negative syscall numbers at the Mach microkernel and positive syscall numbers at the BSD monolithic kernel ­— see xnu/osfmk/mach/syscall_sw.h and xnu/bsd/kern/syscalls.master. Linux's syscall numbers vary by architecture — see linux/arch/powerpc/include/asm/unistd.h, linux/arch/x86/include/asm/unistd_32.h, and linux/arch/x86/include/asm/unistd_64.h — but are all nonnegative. So obviously syscall numbers, syscall arguments, and even which syscalls exist are different.

The standard C runtime libraries are different too; Darwin mostly inherits FreeBSD's libc, while Linux typically uses glibc (but there are alternatives, like eglibc and dietlibc and uclibc and Bionic).

Not to mention that the whole graphics stack is different; ignoring the whole Cocoa Objective-C libraries, GUI programs on OS X talk to WindowServer over Mach ports, while on Linux, GUI programs usually talk to the X server over UNIX domain sockets using the X11 protocol. Of course there are exceptions; you can run X on Darwin, and you can bypass X on Linux, but OS X applications definitely do not talk X.

Like Wine, if somebody put the work into

  • implementing a binary loader for Mach-O
  • trapping every XNU syscall and converting it to appropriate Linux syscalls
  • writing replacements for OS X libraries like CoreFoundation as needed
  • writing replacements for OS X services like WindowServer as needed

then running an OS X program "natively" on Linux could be possible. Years ago, Kyle Moffet did some work on the first item, creating a prototype binfmt_mach-o for Linux, but it was never completed, and I know of no other similar projects.

(In theory this is quite possible, and similar efforts have been done many times; in addition to Wine, Linux itself has support for running binaries from other UNIXes like HP-UX and Tru64, and the Glendix project aims to bring Plan 9 compatiblity to Linux.)

Somebody has put in the effort to implement a Mach-O binary loader and API translator for Linux!

shinh/maloader - GitHub takes the Wine-like approach of loading the binary and trapping/translating all the library calls in userspace. It completely ignores syscalls and all graphical-related libraries, but is enough to get many console programs working.

Darling builds upon maloader, adding libraries and other supporting runtime bits.

share|improve this answer
New efforts would be far more likely to use binfmt_misc than to have any of their own kernel code, wouldn't they? – SamB Dec 19 '10 at 2:09
@SamB: Ever tried setting up a binfmt_misc handler in a chroot? I think it's rather reasonable to handle binary formats for other UNIX-like systems in the kernel. – ephemient Dec 19 '10 at 2:39
My question is; if you've gotten OS X binaries to run on Linux, why would you need to rewrite OS X libraries and services? Wouldn't they run unchanged on Linux at that point? Is it just about legal issues? – Hubro 19 hours ago

Why OSX applications won't run natively on linux:

First of all OSX uses a different binary format than Linux, so Linux can't execute binaries compiled for OSX (the same way it can't execute binaries compiled for Windows or BSD).

Second of all, if you're talking about GUI applications, Apple's GUI toolkit Cocoa a) is only available for OSX and b) does not run on top of X11.

Why there is no equivalent of wine for OSX applications:

A lot of work had to be done before wine was even halfway usable. Since there is not as much demand for an OSX equivalent, no one has invested the same amount of effort into such a project yet.

share|improve this answer
You know, I didn't even realize that OSX/unix didn't use the same binary format. Do you have a link to more infomration on that? – Falmarri Oct 20 '10 at 18:10
Falmarri: OSX uses the Mach-O format, Linux uses ELF. – sepp2k Oct 20 '10 at 18:21
@Falmarri Not all UNIXes use the same binary format, and even though nearly all the modern ones use ELF, you still can't generally run a binary from one UNIX on another. Heck, I don't think FreeBSD even guarantees that you can run a program for 7.x on 8.x or vice versa, while a Linux program for 1.0 ought to still run on 2.6.x. – ephemient Oct 21 '10 at 13:13

The most important reason why OS X apps will not run on Linux is because those OSes used different syscalls.

Some previous answers mentioned libraries but that is generally not the case - Core Foundation is largely open sourced by Apple under the name CFLite and readily portable to any platform (the Windows version of iTunes actually sits atop of a Windows port of Core Foundation, and with some compiler tweaks, you can directly make CFLite using clang on an Linux distribution) and there are also open-sourced efforts to port Objective-C environment, mainly Foundation and AppKit to Linux, most notably GNUstep, a GNU implementation of OpenStep, which dated earlier than Apple's Cocoa (started off when there still was the company NeXT Computer.)

If someone is determined, they can design a loader that will capture every Mach-O syscall and translate it to the corresponding Linux syscall, as well as dynamically link those open-source library "counterparts" to the binary with appropriate ABI translating.

And just for your information, if you can obtain the source code of the Mach-O application, you may consider port it and it may turn out to be very simple. As an example, the TextEdit app bundled with OS X 10.6 can be directly recompiled linking against GNUstep after stripping a few lines of (non-critical) CF code and thus immediately available under Linux (not to mention the TextEdit shipped with GNUstep was actually a direct recompile of the TextEdit app from NeXTSTEP, the precursor to OS X as well, even retaining its "© 1995 NeXT" label). TextEdit is under BSD license.

share|improve this answer

On 8th of December 2012 new project has been launched - Darling.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.