OSXとLinuxには多くの違いがあることは知っていますが、それらがまったく異なる理由で、根本的に互換性がないのはなぜですか？
承認された回答：
sepp2kが述べたように、バイナリ形式（Mach-OとELF）だけでなく、ABI全体が異なります。
たとえば、LinuxとDarwin / XNU（OS Xのカーネル）はどちらもscを使用します PowerPCおよびint 0x80 / sysenter / syscall x86のsyscallエントリでは、それ以降の共通点はそれほど多くありません。
Darwinは、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を参照してください。 —しかし、すべて非負です。したがって、明らかにシステムコール番号、システムコール引数、さらには 存在するsyscallは異なります。
標準のCランタイムライブラリも異なります。ダーウィンは主にFreeBSDのlibcを継承しますが、Linuxは通常glibcを使用します（ただし、eglibcとdietlibc、uclibcとBionicなどの代替手段があります）。
グラフィックスタック全体が異なることは言うまでもありません。 Cocoa Objective-Cライブラリ全体を無視すると、OS XのGUIプログラムはMachポートを介してWindowServerと通信しますが、Linuxでは、GUIプログラムは通常X11プロトコルを使用してUNIXドメインソケットを介してXサーバーと通信します。もちろん例外もあります。ダーウィンではXを実行でき、LinuxではXをバイパスできますが、OSXアプリケーションは間違いなくXと通信しません。
ワインのように、誰かが作品を入れたら
- Mach-O用のバイナリローダーの実装
- すべてのXNUシステムコールをトラップして適切なLinuxシステムコールに変換する
- 必要に応じてCoreFoundationなどのOSXライブラリの代替を作成する
- 必要に応じてWindowServerなどのOSXサービスの代替品を作成する
そうすれば、Linux上でOSXプログラムを「ネイティブに」実行できる可能性があります。数年前、Kyle Moffetは最初のアイテムでいくつかの作業を行い、Linux用のプロトタイプbinfmt_mach-oを作成しましたが、完成することはなく、他に同様のプロジェクトはありません。
（理論的にはこれは非常に可能であり、同様の取り組みが何度も行われています。Linux自体がHP-UXやTru64などの他のUNIXからのバイナリの実行をサポートしており、GlendixプロジェクトはPlan9の互換性を実現することを目的としています。 Linux。）
誰かが持っている Linux用のMach-OバイナリローダーとAPIトランスレーターを実装するために努力してください！
shinh / maloader – GitHubは、バイナリをロードし、ユーザースペース内のすべてのライブラリ呼び出しをトラップ/変換するというWineのようなアプローチを採用しています。 syscallとすべてのグラフィック関連ライブラリを完全に無視しますが、多くのコンソールプログラムを機能させるには十分です。
関連：Linux –UNIXでウェルカムメッセージを表示する方法は??ダーリンはmaloaderに基づいて構築され、ライブラリやその他のサポートするランタイムビットを追加します。