Configure cross compile linux

Cross-compiling tools package guidelines (Русский)

Совет: В качестве альтернативы для создания кросс-компиляторных пакетов вы можете использовать crosstool-ng и создайте свой собственный набор инструментов полностью автоматизированным способом. crosstool-ng можно найти на crosstool-ng .

Важная заметка

На этой странице описан новый принцип работы, основанный на следующих пакетах:

• mingw-w64-gcc и другие пакеты из mingw-w64-* серии
• arm-none-eabi-gcc и другие пакеты из arm-none-eabi-* серии
• другие пакеты из arm-wince-cegcc-* серии

Совместимость версий

Важно: Использование несовместимых версий пакетов для компиляции цепочек инструментов приводит к неизбежным сбоям. По умолчанию считают все версии несовместимыми.

Следующая стратегия позволяют выбирать совместимые версии gcc, binutils, ядра и библиотеки C:

• Основные правила:
  • существует корреляция между выпусками gcc и binutils, используйте одновременно выпущенные версии;
  • лучше использовать последние заголовки ядра для компиляции libc, но использовать переключатель —enable-kernel (специфично для glibc, другие библиотеки C могут использовать другие соглашения) для обеспечения работы на старых ядрах;

  Сборка кросс-компилятора

  Общий подход к созданию кросс-компилятора:

  1. binutils: Создание cross-binutils, которая связывает и обрабатывает для целевой архитектуры
  2. headers: Установите набор библиотеки C и заголовками ядра для целевой архитектуры
     1. используйте linux-api-headers в качестве ссылки и передайте ARCH=target-architecture для make
     2. создать пакет заголовков libc (описан процесс для Glibc here)

     Источник заголовков и libc будет отличаться для разных платформ.

     Совет: Точная процедура может сильно варьировать, в зависимости от ваших потребностей. Например, если вы хотите создать «клон» системы Arch Linux с теми же версиями ядра и glibc, вы можете пропустить сборку заголовков и передать —with-build-sysroot=/ в configure .

     Наименование пакета

     В имени пакета не должно быть префикса со словом cross- (было предложено ранее, но не было принято в официальных пакетах, возможно, из-за дополнительной длины имен), и должно состоять из имени пакета с префиксом GNU triplet без поля поставщика или со значением «unknown» в поле поставщика; пример: arm-linux-gnueabihf-gcc . Если существует более короткое соглашение об именах (например, mips-gcc ), его можно использовать, но это не рекомендуется.

     Размещение файлов

     Последние версии gcc и binutils используют не конфликтующие пути для sysroot и библиотек. Исполняемые файлы должны быть помещены в /usr/bin/ , чтобы предотвратить возникновение конфликтов, перед всеми ними необходимо указать префикс имени архитектуры.

     Правило, ./configure будет иметь по крайней мере следующие параметры:

     _target=your_target _sysroot=/usr/lib/$ . ./configure \ --prefix=$ \ --sysroot=$ \ --bindir=/usr/bin

     где your_target может быть, например, «i686-pc-mingw32».

     пример

     Это PKGBUILD для binutils для MinGW. Вещи, на которые стоит обратить внимание:

     • указание корневого каталога кросс-окружения
     • использование переменных $ , $ и $ , чтобы сделать код более читабельным
     • удаление дублированных / конфликтующих файлов

     # Maintainer: Allan McRae # cross toolchain build order: binutils, headers, gcc (pass 1), w32api, mingwrt, gcc (pass 2) _target=i686-pc-mingw32 _sysroot=/usr/lib/$ pkgname=$=2.10.1' 'zlib') options=('!libtool' '!distcc' '!ccache') source=(http://ftp.gnu.org/gnu/$/$.tar.bz2) md5sums=('09a8c5821a2dfdbb20665bc0bd680791') build() < cd $/$ mkdir binutils-build && cd binutils-build ../configure --prefix=$ --bindir=/usr/bin \ --with-sysroot=$ \ --build=$CHOST --host=$CHOST --target=$ \ --with-gcc --with-gnu-as --with-gnu-ld \ --enable-shared --without-included-gettext \ --disable-nls --disable-debug --disable-win32-registry make make DESTDIR=$/ install # clean-up cross compiler root rm -r $/$/ >

     Примечание: Во время построения кросс-цепочки всегда выполняйте команды configure и make из определенного каталога (так называемая компиляция вне дерева) и удаляйте весь каталог src после малейшего изменения в PKGBUILD.

     Как и почему

     Почему бы не устанавливать в /opt

     1. Во-первых, согласно Стандарту Файловой Иерархии, эти файлы просто принадлежат /usr . И точка!
     2. Во-вторых, установка в /opt является последней мерой, когда другой опции нет.

     What is that out-of-path executables thing?

     Эта статья или раздел нуждается в переводе

     This weird thing allows easier cross-compiling. Sometimes, project Makefiles do not use CC & co. variables and instead use gcc directly. If you just want to try to cross-compile such project, editing the Makefile could be a very lengthy operation. However, changing the $PATH to use «our» executables first is a very quick solution. You would then run PATH=/usr/arch/bin/:$PATH make instead of make .

     Поиск проблемы

     Что делать, если компиляция не удалась без четкого сообщения?

     Если ошибка возникла во время выполнения configure , прочитайте $srcdir/pkgname-build/config.log . Для ошибки, произошедшей во время компиляции, прокрутите консоль, войдите в систему или найдите слово «error».

     Что означает эта ошибка [error message]?

     Скорее всего, вы допустили некоторые неочевидные ошибки:

     • Слишком много или слишком мало флагов конфигурации. Попробуйте использовать уже проверенный набор флагов.
     • Зависимости повреждены. Например, неуместные или отсутствующие файлы binutils могут привести к загадочной ошибке во время настройки gcc.
     • Вы не добавили export CFLAGS=»» в свою функцию build() (см. bug 25672 в GCC Bugzilla).
     • Для некоторых комбинаций —prefix / —with-sysroot может потребоваться, чтобы каталоги были доступны для записи (что не очевидно из руководства clfs).
     • В sysroot нет ни заголовков ядра или libc.
     • Если google не помогает, отмените текущую конфигурацию и попробуйте более стабильную/проверенную.

     Почему файлы устанавливаются в неправильных местах?

     Различные методы запуска make install приводят к разным результатам. Например, некоторые цели make могут не обеспечивать поддержку DESTDIR , а вместо этого требуют использования install_root . То же самое для tooldir , prefix и других подобных аргументов. Иногда предоставление параметров в качестве аргументов вместо переменных среды, например

     и наоборот, может привести к различным результатам (часто вызванным рекурсивным самовывозом configure/make).

     Смотрите также

     Источник

     Кросс-компиляция под Linux

     Что же у нас есть для кросс-компиляции? Если не считать коммерческих продуктов и мелких поделок, то для того, чтобы скомпилировать любой проект под любую платформу, понадобится Gnu Compiler Collection, или, кратко, GCC. GCC — это один большой набор исходников, но собирать из него кросс-компилятор на каждую новую целевую платформу придётся отдельно.

     Надо сказать, список целевых платформ довольно внушителен.

     Вообще, для того, чтобы работать с GGC надо собрать т. н. Toolchain, набор утилит для компиляции. В toolchain входит помимно GCC, ещё Binutils, предназначенные для манипуляций с объектными и бинарными файлами. Для голого железа (если планируется работать не под ОС на целевой платформы, весьма полезной будет также NewLib — сборник стандартных процедур.

     Binutils

     GCC

     В составе GCC большой набор разнообразных инструментов, однако, скорее всего иметь дело придётся с frontend, который так и называется, gcc. Он сам определяет тип исходного файла и вызывает соответствующий компилятор, а также, по необходимости, линковщик или библиотекарь.

     NewLib

     NewLib — специальная подборка стандартных функций для встраиваемых систем. Она включает в себя libc (функци работы со строками, файлами и т. д.), libm (разнообразные математические функции). Также она обладает широкими возможностями конфигурирования под разнообразные требования.

     Надо сказать, NewLib далеко не единственный выбор. В принципе, если не пользоваться библиотечными функциями, можно вообще без библиотек обойтись, но этот путь сложен и тернист — стандарт си не требует наличия их в т. н. standalone environment 1) . Вполне возможно, есть другие подходящие варианты

     GDB

     GNU Debugger — стандартное средство отладки программ, и, в принципе, необязательно. Возможно, вы предпочтёте графический отладчик или вовсе пользуетесь исключительно printf-style-debug 2) .

     Сборка Toolchain

     Также стоит определить путь, куда будет всё установлено. В терминах GCC это называется prefix. По умолчанию этот путь — /usr/local . Однако по ряду различных причин иногда стоит специально указать другой. Первая причина — поставить в собственную домашнюю директорию, например, если нет root-полномочий на машине или просто его поставить только для себя (впрочем, лучше так не делать). Другая причина — бывает нужда с специальных вариантах сборки, и тогда это стоит делать, чтобы не спутать такую сборку с обычной. Стоит отметить, что компиляторы под различные платформы не перепутываются, так как имеют различные имена: gcc для ARM, например, будет именоваться arm-elf-gcc 3) или arm-linux-gcc , и именно его придётся указывать при компиляции (либо указывать target, тогда gcc сам вызовет нужный). Если же оставить путь по-умолчанию, сборка попадёт в стандартный путь поиска исполняемых файлов — /usr/local/bin , и может вызываться без специального указания пути или модификации $path .

     Для указания prefix у configure есть соответствующая опция: — -prefix=…

     Порядок сборки Toolchain

     Сборка тулчейна в описанной конфигурации состоит из следующих этапов:

     Источник

     Читайте также:  File etc profile linux