Бінарна сумісність між Mac OS X та Linux


27

Підкресліть себе, це питання, ймовірно, здасться наївним та / або нерозумним, побачивши, як я відносно новачок у внутрішній роботі Unix, як систем, і в цілому програмуванні.

Готові? Добре! Я пройду приблизно 3 рівня лудікрозності, зростаючи в міру подальшого розвитку.


У нас є дві системи з подібним обладнанням (головним моментом є процесор, скажімо, стандартний дует Intel Core 2 duo).

Один працює (вставте сюди linux distro: Ubuntu буде використовуватися відтепер), а інший працює, скажімо, Mac OS X.

Один складає еквівалентну програму. Скажімо, щось таке:

int main()
{
    int cat = 33;
    int dog = 5*cat;
    return dog;
}

Код надзвичайно простий, тому що я ще не хочу розглядати наслідки спільних бібліотек.

При складанні у відповідних системах. Хіба не головна відмінність між виведенням - питання ELF проти Mach-O? Якби кожен знімав кожне бінарне форматування, залишаючи плоский двійковий, чи не були б розібрані машинні інструкції однаковими? (з, можливо, кількома відмінностями залежно від звичок / схильностей компіляторів).

1.) Якби розробити програму для перепакування плоскої бінарної системи, що виробляється з нашої системи Ubuntu, у форматі Mach-O, вона працювала б у системі Mac OS X? Тоді, якби у вас був тільки складений бінарний файл передбачуваної програми вище, і у нього був цей містичний інструмент для перепакування плоских бінарних файлів, чи змогли б прості програми запускатися в системі Mac OS X?


Тепер давайте трохи підемо далі.

Зараз у нас є програма з джерелом, наприклад:

#include <stdio.h>
int main()
{
    printf("I like tortoises, but not porpoises");
    return 0;
}

2.) Якщо припустити, що ця програма складена і статично пов'язана, чи зможе наша магічна програма все-таки перепакувати сировину у форматі Mach-O і чи зможе вона працювати на mac os X? Бачачи, що не потрібно покладатися на будь-які інші двійкові файли (для яких система mac не мала б у цьому випадку)


А тепер для остаточного рівня;

3.) Що робити, якщо ми використовували цю передбачувану програму для перетворення всіх необхідних спільних бібліотек у формат Mach-O, а потім замість цього компілювали програму вище за допомогою динамічного посилання. Чи вдасться програму все-таки запустити?

Так і повинно бути, очевидно, що кожен крок абсурду покладається на попередню базу, щоб навіть мати сенс. тож якщо перший стовп буде зруйнований, я сумніваюся, що було б багато заслуг для решти ярусів.

Я точно не хотів би навіть думати про це з програмами, які мають на увазі графічний інтерфейс. Віконні системи, ймовірно, будуть зовсім іншим головним болем. На цьому етапі я розглядаю лише програми командного рядка.

Тепер я закликаю світ виправити мене і розповісти мені все, що не так з моєю абсурдною думкою.


еквівалент бінарних файлів Wine for OS X - Дарлінг: darling.dolezel.info
strugee

Відповіді:


25

Ви забуваєте одне важливе, а саме те, що ваша програма повинна буде взаємодіяти з операційною системою, щоб зробити щось цікаве.

Конвенції відрізняються між Linux та OS X, тому один і той же двійковий файл не може працювати як-є без того, щоб по суті мати шматок коду, залежного від операційної системи, щоб мати можливість взаємодіяти з ним. Багато з цих речей приховано в бібліотеках, до яких вам потім потрібно зв’язати, а це означає, що ваша програма повинна бути пов’язаною, а зв'язок також відрізняється між двома системами.

І так воно триває і далі. Те, що на поверхні звучить як те саме, дуже актуально у фактичних деталях.


5
Це, в основному, правильно, в чому полягає проблема, але проблема справді не бібліотеки (яку можна перетягнути), а системні виклики, які є запитами до ядра ОС. Якщо ОС не забезпечує сумісний інтерфейс системного дзвінка, вам не пощастить.
mattdm

1
Ааа, це чудово. Це саме та конструктивна корекція, на яку я сподівався. Дякуємо, купу: D Чи можете ви мені більше розповісти про ці передбачувані системні дзвінки чи перенаправити мене кудись, щоб я дізнався більше про них?
zec

3
Вони не "передбачаються", вони є фактичними. :) Ось вдалий початок: ibm.com/developerworks/linux/library/l-system-calls
mattdm

7
Однак, ваша "божевільна" ідея не зовсім неможлива. Просто багато роботи. Проект Wine по суті це для запуску бінарних файлів MS Windows на Linux (або OS X). Він забезпечує рівень перекладу для системних викликів. wiki.winehq.org/…
mattdm

1
Ну, я вважав, що це не буде абсолютно неможливо, але я також не очікував, що це буде так просто, як я описав. Я написав питання з наміром виправити. Іноді це здається більш ефективним методом потрапляння в основу справи, ніж задавати пряме запитання, наприклад "Як перетворити бінарний файл Linux для роботи на Mac OS". Також я час від часу вживав вино, але ніколи не замислювався над тим, як воно працювало раніше, я думаю, що колись зараз загляну в нього.
zec

17

Це можливо, якщо хтось хоче витратити достатньо часу, щоб це сталося. Проект Дарлінг намагається зробити це, хоча станом на цей текст, він знаходиться у досить примітивному стані.

Це було зроблено успішно раніше на інших платформах:

В OS X є багато FreeBSD , тому перенесення його підтримки Linux може бути простим.


2
Однією з причин цього не є великою справою для програм Linux → інших платформ є: немає значних програм, доступних лише для Linux, для яких джерело недоступне. Ви хочете запустити свою програму на OS X або Solaris, перекомпілюйте її, і там ви йдете. Там, де код написаний специфічним для Linux способом, може бути невеликий перенос, але це, як правило, не багато роботи, особливо порівняно із підтриманням рівня сумісності. Сумісність FreeBSD з Linux була великою справою назад, коли Netscape був двійковим файлом, розподіленим лише для Linux, і, ймовірно, все ще використовується для Adobe Flash Player.
mattdm

@ Jörg W Mittag - також вам потрібно було мати доступні системні бібліотеки з іншої платформи. Це, можливо , було підставою для їх позову проти AutoZone. Але, чесно кажучи, я забуваю деталі і ледве переживаю більше. :)
mattdm

Отже, те, що ви говорите, по суті, що якщо операційна система X надає ті самі послуги, що й операційна система Y, то двійковий файл може працювати під обома. Це правда, але вимагають цілеспрямованих зусиль для системи X. Я не знаю, чи сумісна будь-яка операційна система з OS X.
Thorbjørn Ravn Andersen

биттертен? Я покажу себе.
GnP

3

Я майже погоджуюся з усіма, але хочу додати, що, хоча це займе значну кількість часу та зусиль, це було б не стільки, скільки потрібно для розробки вина.

Багато з проблем у розробці Wine полягає в тому, що вони переносять бінарний формат із операційної системи із закритим джерелом, і МНОГО системних викликів є недокументованими. Вони повинні були по суті реверсувати інженер операційну систему.

Якщо хтось повинен зробити це з однієї відкритої ОС в іншу відкриту ОС, він, швидше за все, може це зробити за 1/10 часу, оскільки рівень сумісності цілком можливо можна скопіювати / вставити з іншої ОС, якщо еквівалент рідної системної виклику не існує. Звичайно, у більшості випадків у всьому світі POSIX буде доступний нативний дзвінок.

Ще один примітний проект - ReactOS, де вони, по суті, створюють повну бінарну сумісну версію Windows ... немає необхідності у Wine.


1

Це технічно можливо в macOS, але не без значних зусиль, хоча деякі зусилля вже зроблені для нас.

  • І macOS, і ребрендований Red Hat Enterprise Linux отримали сертифікат UNIX 03. Це означає, що POSIX-дзвінки повинні мати однаковий API.
  • І macOS, і Linux використовують System V ABI для платформи amd64. Це означає, що для amd64 macOS та Linux повинні мати сумісні ABI та API.
  • macOS використовує Mach-O як свій вихідний виконуваний формат, тоді як Linux використовує ELF. Це робить все простіше, оскільки формат виконуваного файлу можна використовувати, щоб визначити, чи слід викликати рівень сумісності. Для цього потрібно щось подібне binfmt_misc.
  • Існує стороннє розширення ядра macOS, яке забезпечує саме це. Тепер у нас є спосіб переконати macOS у завантаженні ELF, нам потрібен наш спеціальний, ld-linux.soякий сам є виконавчим механізмом Mach-O, який би завантажував наш ELF і запускав його.

Тепер нам потрібно щонайменше спеціальне, ld-linux.soщо може зробити наступне:

  • Будь виконуваний файл Mach-O або dyldсам,
  • Можна завантажити файли ELF Linux у пам'ять за правильною адресою,
  • Сподівається , є можливість відображення Linux ігноровані на MacOS них (наприклад , /lib/libc.so.6до /lib/libSystem.B.dylib) і навантаження , відповідних Mach-O , коли відповідний ELF, не знайдено, тому ми можемо використовувати MacOS бібліотеку

Щойно із завантажувачем вище ELF, який не здійснює прямих системних дзвінків, є хороші шанси на роботу, але ELF із системою викликів може не працювати. Другим компонентом, який може бути корисним, буде розширення ядра, яке захоплює ці систематичні виклики Linux і відображає їх у macOS. У настільних застосувань, спеціальна реалізація Меса необхідна для зіставлення Linux графічних викликів на OpenGL.frameworkі Metal.framework.


0

Існує ряд спеціалізованих додатків для Linux, для яких це буде чудовою підмогою. Що стосується FPGA, Quartus і Vivado є хорошими прикладами програм, які працюють під Linux, і навряд чи для них або подібних програм, які орієнтуються на останні FPGA, не буде доступний вихідний код.

Я думаю, що відповідь на ваше запитання проста: перекомпілюйте в MacOS, де у вас є джерело, і сформуйте групу для забезпечення можливостей, якщо у вас є час - і це буде трудомістким завданням.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.