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

Указания по созданию пакетов

CLR – Cross – Eclipse – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel – Lisp – MinGW – Nonfree – OCaml – Perl – PHP – Python – Ruby – VCS – Web – Wine

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

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

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

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 могут использовать другие соглашения) для обеспечения работы на старых ядрах;
Официальные репозитории: вам, возможно, придется использовать дополнительные исправления и хаки, для версий используемых в Arch Linux (или специфичные ответвления для архитектуры), скорее всего, созданные для совместной работы;
Документация по программному обеспечению: все программное обеспечение GNU README и NEWS файлы, документирующие такие вещи, как минимально необходимые зависимости;
Другие дистрибутивы: они тоже делают кросс-компиляцию
https://clfs.org описывает шаги, необходимые для построения кросс-компилятора, и упоминает несколько актуальных версий зависимостей.

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

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

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

Источник заголовков и 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/${_target}
...
./configure \
    --prefix=${_sysroot} \
    --sysroot=${_sysroot} \
    --bindir=/usr/bin

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

пример

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

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

# Maintainer: Allan McRae <[email protected]>

# cross toolchain build order: binutils, headers, gcc (pass 1), w32api, mingwrt, gcc (pass 2)

_target=i686-pc-mingw32
_sysroot=/usr/lib/${_target}

pkgname=${_target}-binutils
_pkgname=binutils
pkgver=2.19.1
pkgrel=1
pkgdesc="MinGW Windows binutils"
arch=('i686' 'x86_64')
url="http://www.gnu.org/software/binutils/"
license=('GPL')
depends=('glibc>=2.10.1' 'zlib')
options=('!libtool' '!distcc' '!ccache')
source=(http://ftp.gnu.org/gnu/${_pkgname}/${_pkgname}-${pkgver}.tar.bz2)
md5sums=('09a8c5821a2dfdbb20665bc0bd680791')

build() {
  cd ${srcdir}/${_pkgname}-${pkgver}
  mkdir binutils-build && cd binutils-build

  ../configure --prefix=${_sysroot} --bindir=/usr/bin \
    --with-sysroot=${_sysroot} \
    --build=$CHOST --host=$CHOST --target=${_target} \
    --with-gcc --with-gnu-as --with-gnu-ld \
    --enable-shared --without-included-gettext \
    --disable-nls --disable-debug --disable-win32-registry
  make
  make DESTDIR=${pkgdir}/ install
  
  # clean-up cross compiler root
  rm -r ${pkgdir}/${_sysroot}/{info,man}
}

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

Как и почему

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

Две причины:

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

What is that out-of-path executables thing?

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

Примечания: Необходим перевод. (обсуждение: Talk:Cross-compiling tools package guidelines (Русский)#)

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 CC=arm-elf-gcc

вместо

CC=arm-elf-gcc ./configure

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

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

https://wiki.osdev.org/GCC_Cross-Compiler