Buildroot.

Использование и документация Thomas Petazzoni. Добавления от Karsten Kruse, Ned Ludd, Martin Herren.

Русский перевод версия 0.1 от 15.05.2005, Денис Полевой.

Последняя редакция: $Id: buildroot-documentation.html,v 1.2 2004/12/28 19:15:20 andersen Exp $

О Buildroot.

Buildroot это набор файлов make (сборки) и patches (корректировок), которые позволяют просто сгенерировать cross-compilation (под разные платформы) toolchain (полный набор инструментальных средств) и root filesystem (корневую файловую систему) Вашей target (целевой) Linux системы. Toolchain (инструментарий) cross-compilation (кросс-компиляции) использует uClibc (http://www.uclibc.org/), небольшую стандартную C библиотеку.

Buildroot, в основном, используется людьми, работающими с маленькими или встроенными системами. Встроенные системы часто предназначаются не для распространенных x86 процессоров. Это могут быть PowerPC процессоры, MIPS процессоры, ARM процессоры и так далее.

Сompilation toolchain (инструментарий компиляции) это набор tools (инструментов), которые позволяют скомпилировать код для Вашей системы. Этот инструментарий состоит из компилятора (в нашем случае, gcc), бинарных утилит, таких как ассемблер (assembler) и компоновщик (linker) (в нашем случае, binutils) и стандартной C библиотеки (например GNU Libc, uClibc или dietlibc). В системе, установленной на Вашу станцию разработки, конечно уже есть compilation toolchain (инструментарий компиляции) такой, что Вы можете компилировать приложение, которое выполняется на Вашей системе. Если Вы используете PC платформу, Ваш compilation toolchain (инструментарий компиляции) выполняется на некотором x86 процессоре и генерирует код для x86 процессора. Под большинством Linux систем, compilation toolchain (инструментарий компиляции) использует GNU libc, как стандартную C библиотеку. Этот compilation toolchain называется "host (главный) compilation toolchain", и в более общем случае, система, на которой он выполняется, и на которой Вы работаете, называется "host (главная) система". Compilation toolchain предоставляется посредством дистрибутива, который Вы используете, и Buildroot ничего не может в нем нарушить.

Как было сказано выше, сompilation toolchain, который поставляется с Вашей системой, выполняется и генерирует код для процессора Вашей host (главной) системы. Так как Ваша embedded (встроенная) система, может иметь другой процессор, Вам необходим инструментарий cross-compilation (кросс-компиляции): это compilation toolchain, который выполняется на Вашей host (главной) системе, но, который генерирует код для Вашей target (целевой) системы (и целевого процессора). Например, если Ваша host (главная) система использует x86, и Ваша target (целевая) система использует ARM, обычный compilation toolchain Вашей host (главной) системы выполняется на x86 и генерирует код для x86, в то время, как cross-compilation (кросс-компиляции) toolchain (инструментарий) выполняется на x86 и генерирует код для ARM.

Даже если Ваша embedded (встроенная) система использует x86 процессор, Вам может быть интересен Buildroot, по двум причинам:

Вы можете удивиться, зачем такие tools (инструменты) необходимы, когда Вы можете скомпилировать gcc, binutils, uClibc и все tools (инструменты) вручную. Конечно, сделать так возможно. Но иметь дело со всеми конфигурационными параметрами, со всеми проблемами каждой gcc или binutils версии это очень затратно по времени и неинтересно. Buildroot автоматизирует этот процесс посредством использования Makefiles (сборочных файлов), и имеет коллекцию patches (исправлений) для каждой gcc и binutils версии так, чтобы сборки могли работать на большинстве архитектур.

Получение Buildroot.

Анонимный Subversion доступ.

Новейшая реализация всегда доступна по http://uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2, и прежние реализации так же доступны по http://uclibc.org/downloads/snapshots/.

Мы разрешаем анонимным пользователям (только-чтение) Subversion (svn) доступ. Для получения копии новейшей версии buildroot воспользуйтесь анонимным svn доступом так: svn co svn://uclibc.org/trunk/buildroot

Использование Buildroot.

Buildroot имеет прекрасный configuration tool (конфигурационный инструмент), похожий на один из тех, что Вы можете найти в Linux Kernel (http://www.kernel.org/) или в Busybox (http://www.busybox.org/). Помните, что Вы можете выполнить любую программу, как обычный пользователь. Не нужно иметь права root для конфигурации и использования Buildroot. Первый шаг это выполнение конфигурационной программы:

 $ make menuconfig

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

Когда все сконфигурировано, конфигурационный инструмент генерирует .config файл, который содержит описание Вашей конфигурации. Этот файл будет использован Makefiles, для выполнения того, что необходимо.

Итак, начнем:

 $ make

Эта команда будет скачивать, конфигурировать и компилировать все выбранные инструменты, а в заключении сгенерирует target filesystem (целевую файловую систему). Target filesystem (целевая файловая система) будет названа root_fs_ARCH.EXT, где ARCH указанная Вами архитектура, а EXT зависит от типа целевой файловой системы, выбранного в Target options (целевой секции настроек) конфигурационного инструмента.

Задание целевой файловой системы.

Есть два способа задания результирующей целевой файловой системы:

Задание конфигурации Busybox.

Может быть удобно воспользоваться тем, что Busybox очень конфигурируем. Для этого достаточно следовать простым шагам указанным ниже. Это не оптимальный путь, но это просто и это работает.

  1. Сделайте первую компиляцию buildroot с busybox, без попытки конфигурирования busybox.
  2. Перейдите в build_ARCH/busybox/ и выполните make menuconfig. Появится отличный конфигурационный инструмент и можно будет задать то, что желательно.
  3. Чтобы сохранить Вашу заданную конфигурацию, даже если будет удален набор инструментов кросс-компиляции, скопируйте .config файл в package/busybox/busybox.config.
  4. Выполните компиляцию buildroot снова.

В ином случае, Вы можете просто изменить, без использования конфигурационного инструмента, файл package/busybox/busybox.config если знаете параметры, которые хотите изменить.

Задание конфигурации uClibc.

Также как BusyBox, uClibc предоставляет достаточно конфигурационных параметров. Они позволяют выбрать различную функциональность, в зависимости от Ваших требований и ограничений.

Простейший путь модификации конфигурации uClibc это следовать таким шагам:

  1. Провести первую компиляцию buildroot, без попытки конфигурирования uClibc.
  2. Перейти в директорию toolchain_build_ARCH/uClibc/ и выполнить make menuconfig. Появится отличный конфигурационный помошник, похожий на использовавшийся в Linux Kernel или в Buildroot. Задайте требуемую Вами конфигурацию соответственно.
  3. Скопируйте .config файл в toolchain/uClibc/uClibc.config или toolchain/uClibc/uClibc.config-locale. Первая используется, если Вы не выбрали поддержку локали в Buildroot конфигурации, а вторая используется, если Вы выбрали поддержку локали.
  4. Запустите компиляцию Buildroot снова.

Иначе, без выполнения конфигурационного помошника, можно просто изменить toolchain/uClibc/uClibc.config или toolchain/uClibc/uClibc.config-locale.

Как работает Buildroot.

Как сказано выше, Buildroot это в основном набор Makefiles, которые закачивают, конфигурируют и компилируют программы, задавая правильные параметры. Buildroot также включает некоторые patches (корректировки) для различных программ, преимущественно включенных в cross-compilation toolchain (цепочку инструментов кросс-компиляции) (gcc, binutils и uClibc).

В основном один Makefile на программу и расширением названий этих Makefiles является .mk. Makefiles разделены на три секции:

Каждая из директорий содержит, по крайней мере 2 файла:

Основной Makefile выполняет работу посредством следующих шагов (после того, как выполнена конфигурация):

  1. Создает директорию загрузки (dl/ по умолчанию). Это то место, куда будут загружены tarballs. Интересно отметить, что нахождение tarballs в этой директории удобнее сохранения их где-либо еще, для избегания последующих закачек.
  2. Создает строительную директорию (build_ARCH/ по умолчанию, где ARCH, указанная Вами архитектура). Это место, где будут скомпилированы все программы пользователя.
  3. Создает директорию сборки набора инструментов (toolchain_build_ARCH/ по умолчанию, где ARCH, указанная Вами архитектура). Это место, где будет скомпилирован набор инструментов кросс-компиляции.
  4. Устанавливает директорию перемещения (build_ARCH/staging_dir/ по умолчанию). Это место, где будет установлен набор инструментов кросс-компиляции. Если Вы захотите использовать тот же набор инструментов кросс-компиляции для других целей, таких, как компиляция приложения третьего уровня, Вы можете добавить build_ARCH/staging_dir/bin к Вашей PATH и затем использовать arch-linux-gcc для компиляции Ваших приложений. В порядке установки этой директории перемещения, buildroot вначале очищает ее, а затем создает несколько поддиректорий и взаимосвязей внутри нее.
  5. Создает целевую директорию (build_ARCH/root/ по умолчанию) и каркас целевой файловой системы в ней. Эта директория будет содержать финальную целевую файловую систему. Для ее установки, buildroot вначале удаляет ее, а затем расжимает target/default/skel.tar.gz файл для создания основных поддиректорий и взаимосвязей, копирует каркас доступный по target/default/target_skeleton, а затем убирает ненужные директории
  6. И зависимости TARGETS. Обычно должно быть проверено, если конфигурационный параметр для пакета включен и если это так, пакету "предписывается" быть скомпилированным, посредством его указания в глобальной переменной TARGETS.

Использование инструментария uClibc.

Вы можете решить скомпилировать Ваши собственные программы или другие программы, которыми Buildroot не комплектуется. Для того, чтобы выполнить это, можно использовать toolchain, который сгенерирован Buildroot.

Toolchain, который сгенерирован Buildroot по умолчанию находится в build_ARCH/staging_dir/. Простейший путь использовать его это добавить build_ARCH/staging_dir/bin/ к Вашей переменной окружения PATH, а затем использовать arch-linux-gcc, arch-linux-objdump, arch-linux-ld и так далее.

Например, Вы можете добавить следущее к Вашему .bashrc (предположим, что Вы строите систему для MIPS архитектуры и Buildroot находится в ~/buildroot/):

export PATH=$PATH:~/buildroot/build_mips/bin/

Затем Вы можете просто выполнить:

mips-linux-gcc -o foo foo.c

Важно: не пытайтесь переместить toolchain в другую директорию, это не будет работать. Здесь есть определенные жестко прописанные пути в коде конфигурации gcc. Если название toolchain директории по умолчанию не подходит Вам, пожалуйста, обратитесь к части Использование uClibc toolchain вне buildroot секции.

Использование uClibc toolchain вне buildroot.

По умолчанию, cross-compilation toolchain генерируется внутри build_ARCH/staging_dir/. Но иногда, может потребоваться использовать его где-либо еще, итак, это может быть использовано для компиляции других программ или другими пользователями. Перемещение build_ARCH/staging_dir/ директории куда-либо еще не возможно, так как существуют жестко прописанные пути в коде toolchain конфигурации.

Если Вы хотите использовать сгенерированный toolchain в других целях, Вы можете сконфигурировать Buildroot для генерации кода где-либо, используя такой параметр конфигурационного инструмента: Build options -> Toolchain and header file location, что по умолчанию $(BUILD_DIR)/staging_dir/.

Расположение загружаемых пакетов.

Может быть полезно знать, что различные комплекты пакетов (tarballs), которые загружаются Makefile-ми - все сохраняются в DL_DIR, которая по умолчанию директория dl. Это удобно, например, если Вы хотите получить полную версию Buildroot, о которой известно, что она работает со связанными комплектами пакетов (tarballs). Это позволит Вам регенерировать инструментарий (toolchain) и целевую файловую систему с точными версиями.

Добавление программ к Buildroot.

Эта часть относится только к случаю когда Вы желаете добавить непривилегированное, выполняемое в постранстве пользователя (user-space) программное обеспечение.

Директория пакета.

Прежде всего, создайте директорию в package директории для Вашей программы, например, называемой foo.

Файл Config.in

Затем, создайте файл, называемый Config.in. Этот файл будет содержать часть параметров описания, относящихся к нашей программе foo, что будет использовано и отображено в конфигурационном инструменте (configuration tool). В основном, в нем должно содержаться следующее:

config BR2_PACKAGE_FOO
        bool "foo"
        default n
        help
	      Это комментарий, который объясняет, что есть foo.

Конечно, Вы можете добавить параметры для конфигурирования частных вещей в Вашей программе.

Рабочий Makefile.

В заключение, здесь наиболее сложная часть. Создайте файл, называемый foo.mk. Он будет содержать Makefile правила, которые задают загрузку, конфигурацию, компиляцию и установку программы. Ниже расположен пример, который мы прокомментируем далее.

     1  #############################################################
     2  #
     3  # foo
     4  #
     5  #############################################################
     6  FOO_VERSION:=1.0
     7  FOO_SOURCE:=less-$(FOO_VERSION).tar.gz
     8  FOO_SITE:=http://www.foosoftware.org/downloads
     9  FOO_DIR:=$(BUILD_DIR)/less-$(FOO_VERSION)
    10  FOO_BINARY:=foo
    11  FOO_TARGET_BINARY:=usr/bin/foo
    12
    13  $(DL_DIR)/$(FOO_SOURCE):
    14          $(WGET) -P $(DL_DIR) $(FOO_SITE)/$(FOO_SOURCE)
    15
    16  $(FOO_DIR)/.source: $(DL_DIR)/$(FOO_SOURCE)
    17          zcat $(DL_DIR)/$(FOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
    18          touch $(FOO_DIR)/.source
    19
    20  $(FOO_DIR)/.configured: $(FOO_DIR)/.source
    21          (cd $(FOO_DIR); \
    22                  $(TARGET_CONFIGURE_OPTS) \
    23                  CFLAGS="$(TARGET_CFLAGS)" \
    24                  ./configure \
    25                  --target=$(GNU_TARGET_NAME) \
    26                  --host=$(GNU_TARGET_NAME) \
    27                  --build=$(GNU_HOST_NAME) \
    28                  --prefix=/usr \
    29                  --sysconfdir=/etc \
    30          );
    31          touch $(FOO_DIR)/.configured;
    32
    33  $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured
    34          $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)
    35
    36  $(TARGET_DIR)/$(FOO_TARGET_BINARY): $(FOO_DIR)/$(FOO_BINARY)
    37          $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) install
    38          rm -Rf $(TARGET_DIR)/usr/man
    39
    40  foo: uclibc ncurses $(TARGET_DIR)/$(FOO_TARGET_BINARY)
    41
    42  foo-source: $(DL_DIR)/$(FOO_SOURCE)
    43
    44  foo-clean:
    45          $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) uninstall
    46          -$(MAKE) -C $(FOO_DIR) clean
    47
    48  foo-dirclean:
    49          rm -rf $(FOO_DIR)
    50
    51 #############################################################
    52 #
    53 # параметры Makefile верхнего уровня
    54 #
    55 #############################################################
    56 ifeq ($(strip $(BR2_PACKAGE_FOO)),y)
    57 TARGETS+=foo
    58 endif

Во-первых, этот пример Makefile работает для простой двоичной программы. Для других программ, таких как библиотеки, или более сложные приложения с множеством двоичных программ, он должен быть адаптирован. Посмотрите, как это выполнено в других *.mk файлах в директории package.

В строках 6-11 определено несколько полезных переменных:

Строки 13-14 определяют указание, что закачает tarball с удаленного сайта в директорию загрузки (DL_DIR).

Строки 16-18 определяют указание и соответствующие правила, которые разжимают закаченный tarball. Как Вы можете видеть, это указание зависит от файла tarball, так что предъидущее указание (строки 13-14) вызывается перед выполнением правил текущего указания. Разархивация завершается путем применения touching к скрытому файлу для отметки, что программа, была разжата. Этот способ используется везде в Buildroot Makefile для различных шагов (закачка, разжимание, конфигурирование, компиляция, установка), пока зависимости еще остаются правильными.

Строки 20-31 определяют указание и соответствующие правила, которые конфигурируют программу. Это зависит от предыдущего указания (скрытый .source файл) так, что мы уверены, что программа была расжата. В порядке ее конфигурации, в основном выполняется хорошо известный ./configureскрипт. Так как мы можем производить кросс-компиляцию (cross-compilation) выдаются target, host и build аргументы. Prefix так же устанавливается в /usr, не потому что программа будет установлена в /usr на Вашей главной (host) системе, а потому что так будет на целевой (target). В завершение создается .configured файл для отметки, что программа была сконфигурирована.

Строки 33-34 определяют указание и соответствующие правила, которые компилируют программу. Это указание создаст двоичный файл в директории компиляции и, в зависимости от программ, которые уже сконфигурированы (следовательно, это покажет файл .configured). Обычно выполняется make в директории исходного кода.

Строки 36-38 определяют указание и соответствующие правила, которые установят программу внутри целевой файловой системы. В директории исходного кода должен находиться двоичный файл, для подтверждения того, что программа была скомпилирована. Используется указание install для Makefile программы, при этом передается prefix аргумент так, что Makefile пытается установить программу не в главной (host) системы /usrдиректорию, а в целевой (target) системы /usr директорию. После установки, /usr/man директория в целевой (target) файловой системе удаляется для экономии места.

Строка 40 определяет основное указание о программе, которое, в конечном итоге, будет использовано в верхнем уровне Makefile для закачки, компиляции и затем установки этого пакета. Это указание должно быть первым среди всех зависимостей из всех необходимых зависимостей программы (в нашем примере, uclibc и ncurses) и также зависит от окончательного двоичного файла. Последняя зависимость вызовет все предъидущие зависимости в правильном порядке.

Строка 42 определяет простое указание о том, что закачен был только исходный код программы. Это не используется в нормальной работе Buildroot, но может быть полезно.

Строки 44-46 определяют простое указание очистить сборку программы путем вызова Makefiles с соответствующим параметром.

Строки 48-49 определяют простое указание полностью очистить директорию, в которой программа была разархивирована, сконфигурирована и скомпилирована.

Строки 51-58 добавляют указание foo к списку указаний быть скомпилированной Buildroot, во-первых проверив, что конфигурационные параметры для этого пакета были включены, используя конфигурационный инструмент и, если это так, "предписать" этому пакету быть скомпилированным путем добавления его к глобальной переменной TARGETS. Название, добавляемое к глобальной переменной TARGETS это имя указания этого пакета, как определено в строке 40, которая используется Buildroot для закачки, компиляции и затем установки этого пакета.

Заключение.

Как Вы можете видеть, добавление программ к buildroot просто похоже на написание Makefile, используя уже существующий пример и изменяя его применительно к процессу компиляции программы.

Если у Вас есть пакет программы, которая может быть использована другими, не забудьте выслать коррекцию (patch) разработчикам Buildroot!

Ресурсы.

Для лучшего изучения Buildroot, Вы можете посетить эти вебсайты: