Я разработчик C ++ и в попытке лучше понять кроссплатформенную разработку, я пытаюсь лучше понять некоторые детали реализации компиляторов и то, как именно они создают специфичные для ОС двоичные файлы. В разгар своего исследования я понял, что, по крайней мере, какое-то время большинство компиляторов, которые вы загружали для конкретной платформы, скомпилировали двоичные файлы для этой платформы. Поэтому, если вы загрузили IDE, поставляемую с exe-файлом компилятора для Windows, этот компилятор сможет скомпилировать вашу программу только для приложений Windows x86-x64, а не приложений Linux или Mac.
Теперь я понимаю, что для разных платформ требуются разные двоичные форматы, но что мешает, скажем, визуальному компилятору 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 делает это, и я уверен, что есть и другие.
Когда у вас есть рабочий набор инструментов (компилятор, ассемблер, компоновщик), библиотеки собираются из исходных кодов, и в итоге вы получаете все необходимое для создания исполняемого файла для какой-либо другой платформы.
источник
What would be the business benefit ... I don't think there is any.- это хорошая причина для нежелания делать это.Да, если у вас есть вся информация о вашей целевой платформе, то не должно иметь значения, на какой платформе вы на самом деле работаете.
Есть две проблемы, которые, как правило, возникают:
Они не являются непреодолимыми, конечно. В основном, вы получаете компиляторы, предназначенные для платформы, на которой они работают, потому что это то, что люди хотят.
источник
Я не согласен с вашей предпосылкой. Есть миллионы разработчиков Android и iOS. И все они используют компиляторы, работающие на Windows или Mac, производящие код для совершенно другого компьютера.
Вы не получите кросс-компилятор, если на него нет рыночного спроса. Например, люди, разрабатывающие код для рабочего стола Linux, в основном имеют доступ к рабочему столу Linux и будут использовать компилятор на основе Linux - гораздо быстрее, если вы сможете запускать свое приложение непосредственно на компьютере, на котором оно компилируется, без переноса его по сети, гораздо проще и быстрее иметь отладчик, работающий на той же машине и так далее.
Так сколько же Microsoft заработает, если их компиляторы будут собираться и для Linux? Примерно 0 долларов. Сколько еще программного обеспечения для Windows будет создано? Никто. Сколько еще программного обеспечения для Linux будет создано? Понятия не имею, но это не то, что заботит Microsoft. Какова будет стоимость? Довольно значительно. Компиляторы должны быть без ошибок. Они должны быть проверены.
Еще одна проблема: если вы пишете компилятор для Windows, вам нужен кто-то, кто знает, как писать программы для Windows. Если вы пишете компилятор для Linux, вам нужен кто-то, кто знает, как писать программы для Linux. Если вы напишите компилятор для Linux, работающий под Windows, вам вдруг понадобится гораздо более редкий хлеб разработчика, который знает как Windows, так и Linux.
источник