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

  • 5
    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, 2010 at 5:03
  • 6
    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, 2010 at 1:57
  • 6
    There are secret little apples inside the binaries that only Mac machines can see 
    – bobobobo
    Jan 8, 2014 at 16:52
  • In general different OSes can't run each other's binaries; that's why the practice of distributing software as source tarballs grew up around Unix. Neither MacOS nor Linux are special in this respect: it would be something special if either could run the other's binaries. The more-upvoted comment replying to wrosecrans's comment is totally missing the point of it. :/ Jul 9, 2019 at 4:15

4 Answers 4


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.

  • 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, 2010 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, 2010 at 2:39
  • 1
    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
    Nov 26, 2015 at 21:46

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.

  • 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, 2010 at 18:10
  • Falmarri: OSX uses the Mach-O format, Linux uses ELF.
    – sepp2k
    Oct 20, 2010 at 18:21
  • 1
    @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, 2010 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.


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


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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