Что делает программы OSX не работоспособными в Linux?

40

Я знаю, что существует много различий между OSX и Linux, но что делает их такими совершенно разными, что делает их принципиально несовместимыми?

linux osx executable compatibility Falmarri
источник
5
Итак, почему вы ожидаете, что программы OSX будут работать в Linux? Что насчет этих двух конкретных ОС заставляет вас упомянуть их в этом вопросе, но не любую другую ОС, которая также не может запускать программы OSX?
wrosecrans
6
Это в основном мой вопрос. OSX работает на ядре Unix. Мне было интересно, что в нем такого особенного по сравнению с другими Unix / Linux
Falmarri
6
Внутри двоичных файлов есть секретные маленькие яблоки, которые могут видеть только компьютеры Mac bo
bobobobo
В общем, разные ОС не могут запускать двоичные файлы друг друга; Вот почему практика распространения программного обеспечения в качестве исходных тарболлов выросла вокруг Unix. Ни MacOS, ни Linux не являются особенными в этом отношении: было бы что-то особенное, если бы один из них мог запускать двоичные файлы другого. Комментарий с более высоким рейтингом, отвечающий на комментарий wrosecrans, полностью упускает смысл. : /
Питер Кордес

Ответы:

56

Весь ABI отличается, а не только двоичный формат (Mach-O против ELF), как упоминалось в sepp2k.

Например, в то время как Linux и Darwin / XNU (ядро OS X) используют scв PowerPC и int 0x80/ sysenter/ syscallв x86 для входа в системный вызов, с этого момента не так много общего.

Дарвин направляет отрицательные числа системных вызовов в микроядро Маха и положительные числа системных вызовов в монолитном ядре 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 тоже отличаются; Дарвин в основном наследует libc FreeBSD, в то время как Linux обычно использует glibc (но есть альтернативы, такие как eglibc и dietlibc и uclibc и Bionic).

Не говоря уже о том, что весь графический стек отличается; игнорируя целые библиотеки Cocoa Objective-C, программы с графическим интерфейсом на OS X взаимодействуют с WindowServer через порты Mach, а в Linux программы с графическим интерфейсом обычно общаются с X-сервером через доменные сокеты UNIX с использованием протокола X11. Конечно, есть исключения; вы можете запустить X в Darwin и обойти X в Linux, но приложения OS X определенно не говорят на X.

Как вино, если кто-то положил работу в

  • реализация бинарного загрузчика для Mach-O
  • перехват каждого системного вызова XNU и преобразование его в соответствующие системные вызовы Linux
  • написание замен для библиотек OS X, таких как CoreFoundation, по мере необходимости
  • написание замен для служб OS X, таких как WindowServer, по мере необходимости

тогда можно было бы запустить программу OS X «изначально» в Linux. Несколько лет назад Кайл Моффет немного поработал над первым элементом, создав прототип binfmt_mach-o для Linux, но он так и не был завершен, и я не знаю других подобных проектов.

(Теоретически это вполне возможно, и подобные усилия были предприняты много раз; в дополнение к Wine, в самой Linux есть поддержка запуска двоичных файлов из других UNIX, таких как HP-UX и Tru64, а проект Glendix направлен на обеспечение совместимости Plan 9 с Linux) .

Кто - то уже поставил в попытке реализовать Mach-O двоичный загрузчик и API переводчик для Linux!

shinh / maloader - GitHub использует Wine-like подход к загрузке двоичного файла и перехвату / переводу всех вызовов библиотеки в пользовательском пространстве. Он полностью игнорирует системные вызовы и все графические библиотеки, но этого достаточно, чтобы заставить работать многие консольные программы.

Darling основывается на maloader, добавляя библиотеки и другие вспомогательные биты времени выполнения.

ephemient
источник
Новые усилия с большей вероятностью будут использовать binfmt_misc, чем иметь собственный код ядра, не так ли?
SamB
@SamB: Вы когда-нибудь пытались настроить обработчик binfmt_misc в chroot? Я думаю, что достаточно разумно обрабатывать двоичные форматы для других UNIX-подобных систем в ядре.
2010 года
1
Мой вопрос если у вас есть исполняемые файлы OS X для Linux, зачем вам нужно переписывать библиотеки и службы OS X? Разве они не будут работать без изменений в Linux в этот момент? Это только о юридических вопросах?
Hubro
20

Почему приложения OSX не будут работать в Linux:

Прежде всего OSX использует бинарный формат, отличный от Linux, поэтому Linux не может выполнять двоичные файлы, скомпилированные для OSX (так же, как он не может выполнять двоичные файлы, скомпилированные для Windows или BSD).

Во-вторых, если вы говорите о приложениях с графическим интерфейсом, инструментарий Apple с графическим интерфейсом Cocoa а) доступен только для OSX и б) не работает поверх X11.

Почему нет эквивалента wine для приложений OSX:

Надо было проделать большую работу, прежде чем вино стало пригодным даже на полпути. Поскольку не существует такого большого спроса на OSX-эквивалент, никто еще не вложил столько же усилий в такой проект.

sepp2k
источник
Вы знаете, я даже не осознавал, что OSX / Unix не использует тот же двоичный формат. У вас есть ссылка на дополнительную информацию об этом?
Фалмарри
Falmarri: OSX использует формат Mach-O , Linux использует ELF .
sepp2k
1
@Falmarri Не все UNIX используют один и тот же двоичный формат, и, хотя почти все современные используют ELF, вы все равно не можете запустить двоичный файл из одного UNIX в другой. Черт, я не думаю, что FreeBSD даже гарантирует, что вы можете запустить программу для 7.x на 8.x или наоборот, в то время как программа Linux для 1.0 должна все еще работать на 2.6.x.
Эфимент
5

Самая важная причина, по которой приложения OS X не будут работать в Linux, заключается в том, что эти ОС использовали разные системные вызовы.

В некоторых предыдущих ответах упоминались библиотеки, но, как правило, это не так - Core Foundation в основном открыт от Apple под названием CFLite и легко переносится на любую платформу (версия iTunes для Windows фактически располагается поверх порта Windows Core Foundation, и с некоторые настройки компилятора позволяют напрямую создавать CFLite с использованием clang в дистрибутиве Linux), а также предпринимаются усилия с открытым исходным кодом для переноса среды Objective-C, в основном Foundation и AppKit, на Linux, в частности GNUstep, GNU-реализацию OpenStep, датированную раньше, чем Apple, какао (началось, когда еще была компания NeXT Computer.)

Если кто-то определен, он может спроектировать загрузчик, который будет захватывать каждый системный вызов Mach-O и переводить его в соответствующий системный вызов Linux, а также динамически связывать эти «аналоги» библиотеки с открытым исходным кодом с двоичным файлом с соответствующим переводом ABI.

И просто для вашей информации: если вы можете получить исходный код приложения Mach-O, вы можете подумать о его портировании, и это может оказаться очень простым. Например, приложение TextEdit в комплекте с OS X 10.6 можно напрямую перекомпилировать для связывания с GNUstep после удаления нескольких строк (некритического) кода CF и, таким образом, сразу доступного в Linux (не говоря уже о том, что TextEdit, поставляемый с GNUstep, фактически был прямая перекомпиляция приложения TextEdit из NeXTSTEP, также предшествующего OS X, даже с сохранением его метки «© 1995 NeXT»). TextEdit находится под лицензией BSD.

Макстон Чан
источник