Чому компілятори зазвичай генерують виконувані файли тільки для платформи, на якій вони встановлені?

Я розробник C ++ і, намагаючись краще зрозуміти розробку крос-платформ, я намагаюся краще зрозуміти деякі деталі реалізації компіляторів та те, як саме вони створюють специфічні бінарні файли для ОС. У розпалі свого дослідження я зрозумів, що принаймні на деякий час більшість компіляторів, які ви завантажили на певну платформу, лише компілювали двійкові файли для цієї платформи. Отже, якщо ви завантажили IDE, який постачався з компілятором exe для Windows, тоді цей компілятор зможе скласти вашу програму лише для програм x86-x64 Windows, а не для додатків Linux або Mac.

Тепер я розумію, що для різних платформ потрібні різні бінарні формати, але що ускладнює сказування візуального компілятора C ++ у Windows для створення бінарного виконуваного файлу Linux? Поки у вас є інструкція по збірці для центрального процесора, на який ви працюєте, а також спеціальні бібліотеки для ОС, чи не зможете ви складати виконавчі файли для будь-якої платформи на будь-якій машині?

що ускладнює сказування візуального компілятора C ++ у Windows для створення бінарного виконуваного файлу Linux?

Окрім небажання робити це з боку Microsoft, абсолютно нічого. Перешкоди не технічні.

Ланцюги інструментів розробки - це лише програми, які беруть вклад і виробляють вихід. Visual C ++ виробляє збірку x86, а потім використовує ассемблер для перетворення цього файлу в об'єктний COFF. Якщо Microsoft захотіла зробити так, щоб він генерував ELF, це просто код: приходить збірка, ELF виходить. Немає нічого магічного в об’єктних файлах чи бібліотеках; вони просто краплі даних у добре зрозумілому форматі.

Зрештою, у кам'яну епоху перехресне складання було набагато складніше, тому що частіше за все ви писали б ланцюжок інструментів для своєї цільової платформи в зборі для платформи, де вона буде працювати. Це означало, що якби у світі існували архітектури VAX, M68K та Alpha, повний набір крос-компіляторів вимагатиме написання дев'яти з них, переважно з нуля. (VAX-to-VAX, VAX-to-M68K, VAX-to-Alpha, M68K-to-VAX, M68K-to-M68K тощо). Це трохи перебільшення, оскільки частини компілятора VAX можна повторно використовувати та додається до генераторів коду для кожної цілі (наприклад, VAX, M68K та Alpha, кожен написаний для VAX.)

Ця проблема усунулася, коли ми почали писати компілятори мовою, яка не була прив’язана до певного процесора, наприклад, C. Перехід цього маршруту означає, що ви записуєте всю ланцюжок інструментів один раз у C і використовуєте платформу, написану для локальної платформи. C компілятор для його побудови. (Ви часто використовуєте компілятор, щоб перекомпілювати себе після його завантаження на компілятор локальної платформи, але це ще одне обговорення.) Підсумок цього полягає в тому, що створення крос-компілятора стало по суті тим же зусиллям, що і для створення нативного компілятора на місцева платформа. Єдина істотна відмінність полягає в тому, що десь у процесі збирання ви сказали йому скласти генератор коду для вашої цільової платформи замість тієї для локальної платформи, який був би логічним вибором.

По мірі того, як розвивалася архітектура компіляторів, стало зручно просто включати та створювати всі генератори коду з продуктом та вибирати, який із них використовуватимуться під час виконання. Clang / LLVM це робить, і я впевнений, що є й інші.

Після того, як у вас є робоча ланцюжок інструментів (компілятор, асемблер, посилання), бібліотеки збираються з джерел, і в кінцевому підсумку ви отримуєте все необхідне для створення виконуваного файлу для якоїсь іншої платформи.

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

Є дві проблеми, які, як правило, з'являються:

1. Люди не зосереджуються на цьому, оскільки це менш поширений сценарій. Часто єдине, що перетинаєш компілятор, - це компілятор, щоб потім можна було зупинити перехресне компілювання. Менше фокусування означає гіршу підтримку.
2. Нетривіальні програми потребують більше, ніж просто код. Робота з включенням / зв’язком бібліотеки стає трохи легшою, коли у вас є бібліотеки для платформи, на якій ви працюєте. Вони будуть знаходитись у відомому місці, у добре відомому кодуванні.

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

Я не згоден з вашою умовою. Є мільйони розробників Android та iOS. І всі вони використовують компілятори, що працюють на Windows або Mac, створюючи код для зовсім іншого комп'ютера.

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

Так скільки б більше грошей заробило Microsoft, якщо їх компілятори також створили б для Linux? Приблизно $ 0. Скільки ще програмного забезпечення для Windows було б створено? Жоден. Скільки ще було б створено програмне забезпечення Linux? Ніякої ідеї, але Microsoft не про що піклується. Якою була б вартість? Досить помітно. Компілятори повинні бути без помилок. Вони повинні бути протестовані.

Ще одна проблема: якщо ви пишете компілятор, який пише в Windows, вам потрібен хтось, хто вміє писати програмне забезпечення для Windows. Якщо ви пишете компілятор для Linux, вам потрібен хтось, хто вміє писати програмне забезпечення для Linux. Якщо ви пишете компілятор для Linux, що працює в Windows, раптом вам знадобиться набагато рідкісніший хліб розробника, який знає і Windows, і Linux.