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.
- Использование Buildroot.
- Настройка target filesystem.
- Настройка конфигурации Busybox.
- Настройка конфигурации uClibc.
- Как работает Buildroot.
- Использование uClibc toolchain.
- Использование uClibc toolchain вне Buildroot.
- Местонахождение загружаемых пакетов.
- Расширение Buildroot с помощью дополнительных программ.
- Ресурсы.
О 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, по двум причинам:
- Compilation toolchain Вашей host системы несомненно использует GNU Libc, которая является полной, но огромной стандартной C библиотекой. Взамен использования GNU Libc на Вашей target системе, Вы можете использовать uClibc, которая является небольшой стандартной C библиотекой. Если Вы желаете использовать эту C библиотеку, Вам будет необходим compilation toolchain для генерации бинарных кодов, скомпонованных с ней. Buildroot может сделать это для Вас.
- Buildroot автоматизирует построение root filesystem со всеми необходимыми tools (инструментами), например, как busybox. Так гораздо легче, чем собирать все вручную.
Вы можете удивиться, зачем такие 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
(целевой секции настроек) конфигурационного инструмента.
Задание целевой файловой системы.
Есть два способа задания результирующей целевой файловой системы:
- Задать целевую файловую систему прямо и пересобрать образ. Целевая файловая система доступна под
build_ARCH/root/
гдеARCH
, выбранная целевая архитектура. Вы можете просто провести Ваши изменения здесь и выполнить make после, что приведет к пересбору образа целевой файловой системы. Этот метод позволяет вносить любые изменения в целевую файловую систему, но если Вы решите полностью пересобрать Ваш набор инструментов и программ, указанные изменения будут потеряны. - Задание каркаса целевой файловой системы, доступно под
target/default/target_skeleton/
. Здесь Вы можете задать конфигурационные файлы или другое наполнение. Тем не менее, полностью файловая иерархия еще не существует, потому-что она создается в течении процесса компиляции. Итак, Вы не можете делать, что угодно с каркасом этой целевой файловой системы, но изменения в ней останутся, даже если Вы полностью пересоберете кросс-компиляцией набор инструментов и программ.
Вы можете также определитьtarget/default/device_table.txt
файл, который используется инструментами, которые генерируют образ целевой файловой системы с правильно установленными правами доступа и создают ноды /nodes/ устройств. Файлtarget/default/skel.tar.gz
содержит основные директории корневой файловой системы и нет очевидной причины, по которой, он должен быть изменен. Эти основные директории в tarball, внутри каркаса, так как они содержат symlinks (взаимосвязи), которые будут нарушены в ином случае.
Задание конфигурации Busybox.
Может быть удобно воспользоваться тем, что Busybox очень конфигурируем. Для этого достаточно следовать простым шагам указанным ниже. Это не оптимальный путь, но это просто и это работает.
- Сделайте первую компиляцию buildroot с busybox, без попытки конфигурирования busybox.
- Перейдите в
build_ARCH/busybox/
и выполнитеmake menuconfig
. Появится отличный конфигурационный инструмент и можно будет задать то, что желательно. - Чтобы сохранить Вашу заданную конфигурацию, даже если будет удален набор инструментов кросс-компиляции, скопируйте
.config
файл вpackage/busybox/busybox.config
. - Выполните компиляцию buildroot снова.
В ином случае, Вы можете просто изменить, без использования конфигурационного инструмента, файл package/busybox/busybox.config
если знаете параметры, которые хотите изменить.
Задание конфигурации uClibc.
Также как BusyBox, uClibc предоставляет достаточно конфигурационных параметров. Они позволяют выбрать различную функциональность, в зависимости от Ваших требований и ограничений.
Простейший путь модификации конфигурации uClibc это следовать таким шагам:
- Провести первую компиляцию buildroot, без попытки конфигурирования uClibc.
- Перейти в директорию
toolchain_build_ARCH/uClibc/
и выполнитьmake menuconfig
. Появится отличный конфигурационный помошник, похожий на использовавшийся в Linux Kernel или в Buildroot. Задайте требуемую Вами конфигурацию соответственно. - Скопируйте
.config
файл вtoolchain/uClibc/uClibc.config
илиtoolchain/uClibc/uClibc.config-locale
. Первая используется, если Вы не выбрали поддержку локали в Buildroot конфигурации, а вторая используется, если Вы выбрали поддержку локали. - Запустите компиляцию 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 разделены на три секции:
- package (в
package/
директории) содержит Makefiles и соответствующие файлы для всех программ пользователя, которые Buildroot может скомпилировать и добавить в целевую корневую файловую систему. Здесь одна поддиректория на программу. - toolchain (в
toolchain/
директории) содержит Makefiles и соответствующие файлы для всех программ, относящихся к набору инструментов кросс-компиляции:binutils
,ccache
,gcc
,gdb
,kernel-headers
иuClibc
. - target (в
target
директории) содержит Makefiles и соответствующие файлы для всех программ, относящихся к генерации образа целевой корневой файловой системы. Поддерживаются четыре типа файловых систем: ext2, jffs2, cramfs и squashfs. Для каждой из них, здесь есть поддиректория с необходимыми файлами. Здесь такжеgeneric/
директория, которая содержит каркас целевой файловой системы.
Каждая из директорий содержит, по крайней мере 2 файла:
something.mk
это Makefile, который закачивает, конфигурирует, компилирует и устанавливаетsomething (некоторую)
программу.Config.in
это часть файла описания для инструмента конфигурации. В нем указываются параметры, относящиеся к текущей программе.
Основной Makefile выполняет работу посредством следующих шагов (после того, как выполнена конфигурация):
- Создает директорию загрузки (
dl/
по умолчанию). Это то место, куда будут загружены tarballs. Интересно отметить, что нахождение tarballs в этой директории удобнее сохранения их где-либо еще, для избегания последующих закачек. - Создает строительную директорию (
build_ARCH
/ по умолчанию, гдеARCH
, указанная Вами архитектура). Это место, где будут скомпилированы все программы пользователя. - Создает директорию сборки набора инструментов (
toolchain_build_ARCH/
по умолчанию, гдеARCH
, указанная Вами архитектура). Это место, где будет скомпилирован набор инструментов кросс-компиляции. - Устанавливает директорию перемещения (
build_ARCH/staging_dir/
по умолчанию). Это место, где будет установлен набор инструментов кросс-компиляции. Если Вы захотите использовать тот же набор инструментов кросс-компиляции для других целей, таких, как компиляция приложения третьего уровня, Вы можете добавитьbuild_ARCH/staging_dir/bin
к ВашейPATH
и затем использоватьarch-linux-gcc
для компиляции Ваших приложений. В порядке установки этой директории перемещения, buildroot вначале очищает ее, а затем создает несколько поддиректорий и взаимосвязей внутри нее. - Создает целевую директорию (
build_ARCH/root/
по умолчанию) и каркас целевой файловой системы в ней. Эта директория будет содержать финальную целевую файловую систему. Для ее установки, buildroot вначале удаляет ее, а затем расжимаетtarget/default/skel.tar.gz
файл для создания основных поддиректорий и взаимосвязей, копирует каркас доступный поtarget/default/target_skeleton
, а затем убирает ненужные директории - И зависимости
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 определено несколько полезных переменных:
FOO_VERSION
: Версия foo, которая должна быть закаченаFOO_SOURCE
: Название tarball foo на сайте закачки или FTP сайте. Как можно видеть используетсяFOO_VERSION
.FOO_SITE
: HTTP или FTP сайта, с которого foo архив закачивается. Должна включать полный путь к директории, гдеFOO_SOURCE
может быть найденFOO_DIR
: Директория, в которой программа будет сконфигурирована и скомпилирована. В основном, это поддиректорииBUILD_DIR
, которая создается для декомпрессии tarball.FOO_BINARY
: Название двоичного файла программы. Как было сказано ранее, это пример простой двоичной программы.FOO_TARGET_BINARY
: Полный путь к двоичной программе внутри целевой файловой системы (target filesystem).
Строки 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, Вы можете посетить эти вебсайты: