Может ли кто-нибудь объяснить соглашение об именовании кросс-компилятора gcc?
Я попытался понять соглашения об именах, стоящие за кросс-компиляторами gcc, но, похоже, существуют противоречивые ответы. У меня есть следующие три кросс-компилятора в моей системе:
- arm-none-linux-gnueabi (компилятор CodeSourcery ARM для Linux)
- arm-none-eabi (компилятор CodeSourcery ARM для систем с открытым металлом)
- arm-eabi (компилятор Android ARM)
Когда вы читаете руководство GNU libtool, оно определяет соглашение об именах кросс-компиляторов как:
cpu-vendor-os (os = system/kernel-system)
Это не совсем точно с компиляторами в моей системе. Является ли информация, содержащаяся в руководстве GNU, старым, или же дистрибьюторы компилятора просто перестали следовать за ним?
Ответы
Ответ 1
Именование сводится к следующему:
arch-vendor-(os-)abi
Итак, например:
x86_64-w64-mingw32
= архитектура x86_64 (= AMD64), w64 (= mingw-w64 как "поставщик" ), mingw32 (= win32 API, как видно из GCC)
i686-pc-msys
= 32-бит (pc = общее имя) msys binary
i686-unknown-linux-gnu
= 32-разрядный GNU/linux
И ваш пример:
arm-none-linux-gnueabi
= архитектура ARM, нет поставщика, операционной системы Linux и gnueabi ABI.
arm-eabi
аналогичен, как вы говорите, используется для обычных приложений Android.
Одно предостережение: Debian использует другое имя, просто чтобы быть трудным, поэтому будьте осторожны, если вы находитесь в системе на базе Debian, так как у них разные имена, например. i686-pc-mingw32
.
Ответ 2
Дело в том, что есть правило, и оно описано выше от rubenvb. Но в некоторых случаях нанмин, который вы найдете, неверен, так как:
gcc-pippotron-6.3.1-2017.05-x86_64_arm-linux-gnueabihf gcc-pippotron-arm-none-eabi-4.8-2013.11_linux
Это maming выше - 3 примера, которые не соблюдают правило.