Общие вопросы о GCC и кросс-компиляции

Недавно я экспериментировал с кросс-компиляцией с помощью GCC и обнаружил довольно сложную область — цепочки инструментов.

Я не совсем понимаю это, так как у меня сложилось впечатление, что GCC может создавать двоичный машинный код для большинства распространенных архитектур, и все, что действительно имеет значение, это то, с какими библиотеками вы связываетесь и какой тип исполняемого файла создается.

Может ли GCC не делать все это самостоятельно? С одной сборкой GCC, всеми соответствующими библиотеками и правильными флагами, отправленными в GCC, могу ли я создать исполняемый файл PE для машины с Windows x86, затем создать исполняемый файл ELF для встроенного устройства Linux MIPS и, наконец, исполняемый файл для OSX PowerPC машина? Если нет, может ли кто-нибудь объяснить, как вы этого добьетесь?


person ArturPhilibin    schedule 15.12.2010    source источник
comment
одиночная сборка llvm немного мощнее. Он может генерировать код для нескольких арок   -  person osgx    schedule 16.12.2010
comment
объясните, как вы этого добьетесь, создав множество отдельных перекрестных сред.   -  person osgx    schedule 16.12.2010


Ответы (2)


С одной сборкой GCC, всеми соответствующими библиотеками и правильными флагами, отправленными в GCC, могу ли я создать исполняемый файл PE для машины с Windows x86, затем создать исполняемый файл ELF для встроенного устройства Linux MIPS и, наконец, исполняемый файл для OSX PowerPC. машина? Если нет, может ли кто-нибудь объяснить, как вы этого добьетесь?

Нет. Одна сборка GCC создает объектный код для одной целевой архитектуры. Вам потребуется сборка для Intel x86, сборка для MIPS и сборка для PowerPC. Однако компилятор — не единственный инструмент, который вам нужен, несмотря на то, что вы можете преобразовать исходный код в исполняемый файл одним вызовом GCC. Под капотом он также использует ассемблер (as) и компоновщик (ld), которые должны быть созданы для целевой архитектуры и платформы. Обычно GCC использует версии этих инструментов из пакета GNU binutils, поэтому вам также потребуется собрать его для целевой платформы.

Подробнее о создании набора инструментов для кросс-компиляции можно прочитать здесь.

Я не совсем понимаю это, так как у меня сложилось впечатление, что GCC может создавать двоичный машинный код для большинства распространенных архитектур.

Это верно в том смысле, что исходный код самого GCC может быть встроен в компиляторы, предназначенные для различных архитектур, но вам все равно потребуются отдельные сборки.


Относительно -march это не позволяет одной и той же сборке GCC переключаться между платформами. Скорее, он используется для выбора допустимых инструкций для одного и того же семейства процессоров. Например, некоторые инструкции, поддерживаемые современными процессорами x86, не поддерживались самыми ранними процессорами x86, потому что они были введены позже (например, наборы расширенных инструкций, такие как MMX и SSE). Когда вы передаете -march, GCC включает все коды операций, поддерживаемые этим процессором и его предшественниками. Чтобы процитировать руководство GCC:

При выборе определенного типа процессора все будет планироваться соответствующим образом для этого конкретного чипа, но компилятор не будет генерировать код, который не работает на i386 без использования параметра -march=cpu-type.

person Nick Meyer    schedule 15.12.2010
comment
Означает ли это, что возможность создания машинного кода для всех этих архитектур есть в исходном коде GCC, но вы должны выбрать одну и только одну во время компиляции? Также теперь я не понимаю, для чего нужен флаг -march= - person ArturPhilibin; 16.12.2010
comment
Да, вы должны выбрать архитектуру во время компиляции. См. мою правку относительно -march. - person Nick Meyer; 16.12.2010
comment
Между прочим, вполне возможно сосуществование нативных и кросс-компиляторов на одной и той же машине разработки. Даже несколько кросс-компиляторов для разных целей возможны, если вы будете осторожны с тем, как вы их называете, и с вашим PATH. - person Nick Meyer; 16.12.2010
comment
-march не заставляет gcc воздерживаться от генерации кодов операций. Это позволяет gcc генерировать коды операций, которые в противном случае были бы запрещены, потому что они не существуют на 80386/7. - person R.. GitHub STOP HELPING ICE; 16.12.2010

Если вы хотите попробовать кросс-компиляцию и не хотите самостоятельно создавать цепочку инструментов, я бы порекомендовал взглянуть на CodeSourcery. У них есть набор инструментов на основе GNU, а их бесплатная версия "Lite" поддерживает довольно много архитектуры. Я использовал его для Linux/ARM и Android/ARM.

person Ravi    schedule 16.12.2010