Может ли кто-нибудь объяснить соглашение об именовании кросс-компилятора 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 примера, которые не соблюдают правило.