Linux build host target

Кросс-сборка gcc с другими host и target

Я пытаюсь собрать gcc 4.8.2 с —host и —target отличными от —build (конкретно — host и target = «arm-unknown-linux-gnueabi», build = «x86_64-pc-linux-gnu»). Система — gentoo.

gmp, mpfr и mpc в build-системе есть и отлично работают, но, тем не менее, во время ./configure gcc пытается устроить self-test и слинковать тестовый бинарник с вышеозначенными библиотеками, но при этом использует кросс-компилирующий arm-unknown-linux-gnueabi-gcc, который очень удивляется библиотекам от x86_64 и ожидаемо говорит «/usr/lib/libmpc.so: file not recognized», после чего сборка заканчивается.

Как я посмотрел (ldd `which gcc`), скомпилированные компиляторы от этих библиотек не зависят.

Существует ли какой-нибудь способ сказать gcc, что он неправ и для тестирования системы сборки стоит использовать другой компилятор?

Используй crosstool-ng. Стандартное средство сборки кросс тулчейнов, умеет выкачивать нужные зависимости. Есть профиль для arm-unknown-linux-gnueabi.

Но у меня уже есть тулчейн с host=x86_64-pc-linux-gnu и target=arm-unknown-linux-gnueabi, зачем мне еще один? Мне нужно собрать gcc, который будет работать ARM и собирать под ARM.

crosstool-NG позволяет собрать тулчейн с любой комбинацией build-host-target, в том числе т.н. canadian build (build!=host!=target).

в ./configure —help нету какой-нибудь опции, отключающей эти тесты?

Вспомнил, то что тебе нужно называется cross-native

который будет работать ARM и собирать под ARM.

В смысле «будет работать _на_ ARM» ? Вообще непонятно, в чём проблема тогда.

В общем, вот тут кое-что собрано, если речь про сборку для arm не на arm: http://code.google.com/p/starterkit-org/w/list
В том числе и crosstool-ng упоминается.

Вообще-то, такие вещи проще собирать в чруте или через distcc. Дистростроители так и делают. Тесты отключать не рекомендуется. Более того, если тулчейн собирается не только для себя, надо провести бутстраппинг.

Я спросил в IRC-конфе crosstool-ng — автор утверждает, что он не может делать cross-native.

Странно, на главной упомянута поддержка canadian build. Возможно, нужны какие-то костыли, я сам не собирал.

Canadian build поддерживается, а cross-native — нет.

Canadian build поддерживается, а cross-native — нет.

Потому что это никому не нужно. Если производительность процессора такая что нативная компиляция в затяжной геморой не превращается — поставь свой любимый дистрибутив на целевой платформе и не мучайся.

Источник

Buildroot — часть 1. Общие сведения, сборка минимальной системы, настройка через меню

Введение

В данной серии статей я хочу рассмотреть систему сборки дистрибутива buildroot и поделиться опытом её кастомизации. Здесь будет практический опыт создания небольшой ОС с графическим интерфейсом и минимальным функционалом.

Прежде всего, не следует путать систему сборки и дистрибутив. Buildroot может собрать систему из набора пакетов, которые ему предложили. Buildroot построен на make-файлах и поэтому имеет огромные возможности по кастомизации. Заменить пакет на другую версию, добавить свой пакет, поменять правила сборки пакета, кастомизировать файловую систему после установки всех пакетов? Всё это умеет buildroot.

В России buildroot используется, но на мой взгляд мало русскоязычной информации для новичков.

Цель работы — собрать дистрибутив с live-загрузкой, интерфейсом icewm и браузером. Целевая платформа — virtualbox.

Зачем собирать свой дистрибутив? Зачастую нужен ограниченный функционал при ограниченных ресурсах. Ещё чаще в автоматизации нужно создавать прошивки. Приспосабливать дистрибутив общего назначения, вычищая лишние пакеты и превращать его в прошивку путь более трудоёмкий, чем собрать новый дистриб. Использование Gentoo тоже имеет свои ограничения.

Buildroot система очень мощная, но она ничего не сделает за вас. Она может лишь дать возможности и автоматизировать процесс сборки.

Альтернативные системы сборки (yocto, open build system и прочие) не рассматриваются и не сравниваются.

Где взять и как начать

Сайт проекта — buildroot.org. Здесь можно скачать актуальную версию и прочитать руководство. Там же можно обратиться к сообществу, есть багтрекер, mail-lists и irc-канал.

Buildroot оперирует defconfig’aми для целевой платы сборки. Defconfig — это конфигурационный файл, хранящий в себе только опции, не имеющими значения по умолчанию. Именно он определяет, что и как будет собрано. При этом можно отдельно настроить конфиги busybox, linux-kernel, uClibc, загрузчиков u-boot и barebox, но все они будут привязаны к целевой плате.
После распаковки скачанного архива или клонировании из git получаем готовый к работе buildroot. Подробно о структуре каталогов можно прочитать в руководстве, расскажу о самых важных:

board — каталог с файлами, специфичными для каждой платы. Это могут быть скрипты формирования образов системы(iso, sdcart, cpio и прочие), каталог overlay, конфиг ядер и прочее
configs — собственно defconfig платы. Defconfig — это неполная конфигурация платы. В нем хранится только отличные от дефолтных настроек параметры
dl — каталог со скачанными исходными кодами/файлами для сборки
output/target — собранная файловая система полученной ОС. В дальнейшем из нее создаются образы для загрузки/установки
output/host — host-утилиты для сборки
output/build — собранные пакеты

Конфигурирование сборки осуществляется через KConfig. Эта же система используется для сборки ядра linux. Список самых часто используемых команд (выполнять в каталоге buildroot):

• make menuconfig — вызвать настройку сборки. Так же можно с использование графического интерфейса (make nconfig,make xconfig,make gconfig)
• make linux-menuconfig — вызвать конфигурацию ядра.
• make clean — очистить результаты сборки (всё что храниться в output)
• make — собрать систему. При этом не выполняется пересборка уже собранных процессов
• make defconfig_name — переключить конфигурацию на определенный defconfig
• make list-defconfigs — показать список defconfig’ов
• make source — только скачать установочный файлы, без сборки.
• make help — вывести список возможных команд

Важные замечания и полезные советы

Buildroot не пересобирает уже собранные пакеты! Поэтому может создаться ситуация, когда потребуется полная пересборка.

Можно пересобрать отдельный пакет командой make packagename-rebuild. Например, можно пересобрать ядро linux:

Buildroot хранит состояние любого пакета созданием .stamp-файлов в каталоге output/build/$packagename:

Следовательно, можно пересобрать root-fs и образы без пересборки пакетов:

Полезные переменные

В buildroot есть набор переменных для удобного конфигурирования

• $TOPDIR — корневой каталог buildroot
• $BASEDIR — каталог OUTPUT
• $HOST_DIR, $STAGING_DIR, $TARGET_DIR — каталоги сборки host fs, staging fs, target fs.
• $BUILD_DIR — каталог c распакованными и собранными пакетами

Визуализация

В buildroot есть возможность по визуализации.Можно построить схему зависимостей, график времени сборки, график размера пакетов в итоговой системе. Результаты в виде pdf файлов( на выбор есть svn,png) в каталоге output/graph.

Примеры команд визуализации:

• make graph-depends построить дерево зависимостей
• make

-graph-depends построить дерево зависимостей конкретного пакета

BR2_GRAPH_OUT=png make graph-build построить график времени сборки с выводом в PNG

make graph-size построить график размера пакетов

Полезные скрипты

В каталоге buildroot есть подкаталог utils c полезными скриптами. Например, там есть скрипт, проверяющий корректность описания пакетов. Это может быть полезно при добавлении своих пакетов (я это сделаю позже). В файле utils/readme.txt есть описание этих скриптов.

Соберем cтоковый дистрибутив

Важно напомнить, что все операции ведутся от лица обычного пользователя, не root.
Все команды выполняются в корне buildroot. В поставке buildroot уже есть набор конфигураций под многие распространённые платы и виртуализацию.

Смотрим список конфигураций:

Переключаемся на конфиг qemu_x86_64_defconfig

И запускаем сборку

Сборка завершается успешно, смотрим на результаты:

Buildroot собрал образы, которые можно запустить в Qemu и убедиться, что они работают.

Результат — запущенная в qemu система:

Создание конфигурации собственной платы

Добавление файлов платы

Смотрим список конфигураций:

В списке видим pc_x86_64_bios_defconfig. Мы создадим свою плату, скопировав её с конфигурации:

Сразу же создадим каталог платы для хранения своих скриптов, rootfs-overlay и прочих нужных файлов:

Переключаемся на этот defconfig:

Таким образом, теперь конфиг сборки (хранится в .config в корне каталога buildroot’а) соответствует целевой машине x86-64 legacy(bios) загрузкой.

Скопируем конфигурацию linux-kernel (пригодится в дальнейшем):

Настройка параметров сборки через KConfig

Откроется окно KConfig. Есть возможность конфигурировать с графическим интерфейсом (make nconfig, make xconfig, make gconfig):

Входим в первый раздел Target Options. Здесь можно выбрать целевую архитектуру, под которую будет вестись сборка.

Build options — здесь есть различные настройки сборки. Можно указать каталоги с исходными кодами, количество потоков сборки, зеркала для скачивания исходных кодов и прочие настройки. Оставим настройки по-умолчанию.

Toolchain – здесь настраивается сам инструментарий сборки. О нем подробнее.

Toolchain type – тип используемого тулчейна. Это может быть встроенный в buildroot или внешний тулчейн (можно указать каталог с уже собранным или url для скачивания). Для разных архитектур есть дополнительные опции. Например, для arm можно просто выбрать версию внешнего тулчейна Linaro.

C library – выбор библиотеки С. От этого зависит работа всей системы. Обычно используется glibc, поддерживающая весь возможный функционал. Но она может оказаться слишком большой для встроенной системы, поэтому часто выбирают uClibc или musl. Мы выберем glibc (в дальнейшем это потребуется для использования systemd).

Kernel Headers и Custom Kernel Headers series – должно совпадать с версией ядра, которое будет в собираемой системе. Для kernel headers можно так же указать путь к тарболу или git-репозиторий.

GCC COMPILER VERSIONS – выбор версии компилятора, которая будет использована для сборки
Enable C++ support – выберем для сборки с поддержкой библиотек c++ в системе. В дальнейшем нам это пригодится.

Additional gcc options – можно задать дополнительные опции компилятора. Нам без надобности пока что.

System configuration позволяет задать будущие параметры созданной системы:

Большинство пунктов понятны из названия. Обратим внимание на следующие пункты:
Path to the users tables — таблица с создаваемыми пользователями (https://buildroot.org/downloads/manual/manual.html#makeuser-syntax).

Пример файла. Будет создан пользователь user с паролем admin, автоматически gid/uid, /bin/sh шеллом, группой по-умолчанию user, член группы root, комментарием Foo user

Root filesystem overlay directories — каталог, накладываемый поверх собранной target-fs. Добавляет новые файлы и заменяет имеющиеся.

Custom scripts to run before creating filesystem images — Скрипты, выполняемые непосредственно перед сворачиванием файловой системы в образы. Сам скрипт пока оставим пустым

Перейдём в раздел Kernel

Здесь задаются настройки ядра. Само ядро конфигурируется через make linux-menuconfig.
Задать версию ядра можно по-разному: выбрать из предложенных, ввести версию вручную, указать репозиторий или готовый tarball.

Kernel configuration — путь к конфигу ядра. Можно выбрать конфигурацию по-умолчанию для выбранной архитектуры или defocnfig из Linux. В исходниках Linux есть набор defconfig’ов для разных целевых систем. НАйти нужный можно, глянув напрямую в исходники здесь. Например, для платы beagle bone black можно выбрать конфиг.

Раздел Target packages позволяет выбрать, какие пакеты будут установлены в собираемую систему. Пока оставим без изменений. Позже мы добавим свои пакеты в этот список.
Filesystem images — список образов файловых систем, которые будут собраны. Добавим iso-образ

Bootloaders — выбор собираемых загрузчиков. Выберем isolinix

Конфигурирование Systemd

Systemd становится одним из столбов linux, наравне с kernel и glibc. Поэтому вынес его настройку в отдельный пункт.

Настраивается через make menuconfig, далее Target packages → System tools → systemd. Здесь можно указать, какие службы systemd будут установлены и запущены при старте системы.

Сохранение конфигурации системы

Сохраняем этот конфиг через KConfig.

После чего сохраним наш defconfig:

Конфигурирование ядра Linux

Конфигурирование ядра linux вызывается следующей командой:

Добавим поддержку видеокарты Virtualbox

Добавим Virtualbox Guest integration support

Сохраняем и выходим. ВАЖНО: конфигурация сохранится в output/build/linux-$version/config, но не в board/my_x86_board/linux.config

Поэтому нужно вручную скопировать конфиг в место хранения:

Этой командой я копирую ПОЛНЫЙ конфиг ядра, что нужно не всегда. Более правильный путь — сохранять defconfig ядра:

После чего выполним полную пересборку всей системы.Т.к. buildroot не пересобирает уже собранное, то надо вручную указать пакеты для пересборки. Чтобы не терять время и нервы, небольшую систему проще пересобрать целиком):

По завершении сборки запускаем VirtualBox(проверялось на версии 5.2 и 6.0) с загрузкой с cd-диска.Параметры системы:

Источник