Buildroot用户手册（节选）

Buildroot用户手册

前言

• 从git版本8a94ff12d2于2018-03-04 21:31:16 UTC生成的Buildroot 2018.02手册
• Buildroot手册由Buildroot开发人员编写。 它是根据GNU通用公共许可证版本2许可的。
• 有关此许可证的全文，请参考Buildroot源中的COPYING文件。
• 版权所有©2004-2018 Buildroot开发人员

第一部分-入门

第1章 关于Buildroot

Buildroot是一个工具，它可以使用交叉编译来简化和自动化为嵌入式系统构建完整的Linux系统的过程。

为了实现这一目标，Buildroot能够为您的目标生成交叉编译工具链，根文件系统，Linux内核映像和引导加载程序。 Buildroot可以独立地用于这些选项的任何组合（例如，您可以使用现有的交叉编译工具链，并仅通过Buildroot来构建根文件系统）。

Buildroot主要对使用嵌入式系统的人有用。 嵌入式系统通常使用的处理器不是每个人都已经习惯在其PC中使用的常规x86处理器。 它们可以是PowerPC处理器，MIPS处理器，ARM处理器等。

Buildroot支持众多处理器及其变体。 它还提供了一些现成可用板卡的默认配置。 除此之外，许多第三方项目都基于Buildroot或基于其开发BSP 1或SDK 2。

1.BSP：板级支持包
2.SDK：软件开发套件

第2章 系统要求

Buildroot旨在在Linux系统上运行。

尽管Buildroot会自行构建编译所需的大多数主机软件包，但某些标准Linux实用程序预计已安装在主机系统上。 您将在下面找到强制性软件包和可选软件包的概述（请注意，软件包名称在发行版之间可能有所不同）。

强制安装的包

构建工具：

• which

• sed

• make (version 3.81 or any later)

• binutils

• build-essential (only for Debian based systems)

• gcc (version 2.95 or any later)

• g++ (version 2.95 or any later)

• bash

• patch

• gzip

• bzip2

• perl (version 5.8.7 or any later)

• tar

• cpio

• python (version 2.6 or any later)

• unzip

• rsync

• file (must be in /usr/bin/file) – bc

源获取工具：

• wget

可选的包

• 配置接口依赖性：
  对于这些库，您需要同时安装运行时和开发数据，在许多发行版中，这些数据是单独打包的。
  开发软件包通常具有-dev或-devel后缀。
  – ncurses5使用menuconfig界面
  – qt4使用xconfig接口
  – glib2，gtk2和glade2使用gconfig接口

• 源获取工具：
  在官方树中，大多数软件包源都是使用wget从ftp，http或https位置检索的。 只有版本控制系统才能提供一些软件包。 此外，Buildroot能够通过其他工具（例如rsync或scp）下载源代码（有关更多详细信息，请参见第19章）。 如果使用以下任何一种方法启用软件包，则需要在主机系统上安装相应的工具：– bazaar
  – cvs
  – git
  – mercurial
  – rsync
  – scp
  – subversion

• 与Java有关的软件包，如果需要为目标系统构建Java Classpath：
  – javac编译器
  – jar工具

• 文档生成工具：
  – asciidoc，版本8.6.3或更高版本
  – w3m
  –带有argparse模块的python（在2.7+和3.2+中自动存在）
  – dblatex（仅适用于pdf手册）

• 图形生成工具：
  – graphviz使用图依赖和<pkg> -graph-依赖
  – python-matplotlib使用图构建

第3章 获取Buildroot

Buildroot版本每2个月，2月，5月，8月和11月发布一次。 版本号的格式为YYYY.MM，例如2013.02、2014.08。

可从http://buildroot.org/downloads/获得发行压缩包。

为方便起见，Buildroot源树中的support / misc / Vagrantfile中提供了Vagrantfile，可快速设置具有所需依赖关系的虚拟机以开始使用。

如果要在Linux或Mac Os X上设置隔离的buildroot环境，请将此行粘贴到终端上：

curl -O https://buildroot.org/downloads/Vagrantfile; vagrant up

如果您使用的是Windows，请将其粘贴到您的Powershell中：

(new-object System.Net.WebClient).DownloadFile(

“https://buildroot.org/downloads/Vagrantfile”,“Vagrantfile”);

vagrant up

如果要关注开发，可以使用每日快照或克隆Git存储库。 有关更多详细信息，请参考Buildroot网站的“下载”页面。

第4章 Buildroot快速入门

重要提示：您可以并且应该以普通用户身份来构建所有内容。 无需root用户即可配置和使用Buildroot。 通过以常规用户身份运行所有命令，可以保护系统免受在编译和安装过程中表现异常的软件包的侵害。

使用Buildroot的第一步是创建配置。 Buildroot有一个不错的配置工具，类似于在Linux内核或BusyBox中可以找到的工具。

从buildroot目录运行

$ make menuconfig

对于原始的基于curses的配置器，或者

$ make nconfig

对于新的基于curses的配置器，或者

$ make xconfig

基于Qt的配置器，或

$ make gconfig

用于基于GTK的配置器。

所有这些“ make”命令都将需要构建配置实用程序（包括接口），因此您可能需要为配置实用程序使用的相关库安装“开发”包。 有关更多详细信息，请参见第2章，尤其是第2.2节中的可选要求，以获取您喜欢的接口的依赖性。

对于配置工具中的每个菜单条目，您都可以找到描述条目目的的相关帮助。 有关某些特定配置方面的详细信息，请参见第6章。

完成所有配置后，配置工具将生成一个包含整个配置的.config文件。 该文件将由顶级Makefile读取。

要开始构建过程，只需运行：

$ make

永远不要将make -jN与Buildroot一起使用：当前不支持顶级并行make。 而是使用BR2_JL EVEL选项告诉Buildroot使用make -jN运行每个软件包的编译。
make命令通常将执行以下步骤：

• 下载源文件（根据需要）；
• 配置，构建和安装交叉编译工具链，或仅导入外部工具链；
• 配置，构建和安装选定的目标软件包；
• 构建内核映像（如果选择）；
• 构建引导加载程序映像（如果已选择）；
• 以选定的格式创建根文件系统。

Buildroot的输出存储在单个目录output /中。 该目录包含几个子目录：

• image：存储所有映像（内核映像，引导加载程序和根文件系统映像）的位置。这些是您需要放在目标系统上的文件。
• build：构建所有组件的位置（包括主机上Buildroot所需的工具以及为目标编译的软件包）。该目录包含每个组件的一个子目录。
• staging：包含与根文件系统层次结构相似的层次结构。该目录包含交叉编译工具链的标题和库，以及为目标选择的所有用户空间包。但是，该目录并非旨在作为目标的根文件系统：它包含许多开发文件，未剥离的二进制文件和库，这些文件对于嵌入式系统而言太大了。这些开发文件用于为依赖于其他库的目标编译库和应用程序。
• target：几乎包含目标的完整根文件系统：除了设备外，所有需要的东西都存在
  / dev /中的文件（Buildroot无法创建文件，因为Buildroot不能以root身份运行，也不想以root身份运行）。另外，它没有正确的权限（例如，busybox二进制文件的setuid）。因此，该目录不应在您的目标上使用。相反，您应该使用images /目录中内置的映像之一。如果您需要提取根文件系统的映像以通过NFS引导，请使用images /中生成的tarball映像并将其提取为root。与staging /相比，target /仅包含运行所选目标应用程序所需的文件和库：不存在开发文件（标头等），二进制文件被剥离。
• host：包含为正确执行Buildroot所需的为主机编译的工具的安装，包括交叉编译工具链。

这些命令，make menuconfig | nconfig | gconfig | xconfig和make是基本的命令，它们使您可以轻松，快速地生成符合您需求的图像，并启用所有功能和应用程序。
有关“ make”命令用法的更多详细信息，请参见第8.1节

第5章 社区资源

像任何开源项目一样，Buildroot具有在社区内和外部共享信息的不同方式。
如果您正在寻找帮助，想了解Buildroot或为项目做贡献，那么每种方式都可能使您感兴趣。

• 邮件列表
  Buildroot有一个讨论和开发邮件列表。 它是Buildroot用户和开发人员进行交互的主要方法。
  仅Buildroot邮件列表的订阅者可以发布到该列表。 您可以通过邮件列表信息页面进行订阅。
  发送到邮件列表的邮件也可以在邮件列表档案中找到，也可以通过Gmane在gmane.comp.lib.uclibc.buildroot中获得。 在问问题之前，请先搜索邮件列表档案，因为很有可能其他人之前也曾问过同样的问题。

• IRC

  Buildroot IRC频道#buildroot托管在Freenode上。 这是一个提出快速问题或讨论某些主题的有用地方。
  在IRC上寻求帮助时，请使用代码共享网站（例如http://code.bulix.org）共享相关日志或代码段。
  请注意，对于某些问题，将其发布到邮件列表可能会更好，因为它将吸引更多的开发人员和用户。

• 错误追踪器
  可以通过邮件列表或通过Buildroot Bugtracker报告Buildroot中的错误。 创建错误报告之前，请参阅第21.6节。

• 维基
  Buildroot Wiki页面位于eLinux Wiki上。 它包含一些有用的链接，过去和即将发生的事件的概述以及TODO列表。

• patchwork
  Patchwork是一个基于Web的补丁跟踪系统，旨在促进对开源项目的贡献和贡献的管理。 已发送到邮件列表的补丁被系统“捕获”，并显示在网页上。
  发布的任何引用该修补程序的注释也将附加到修补程序页面。 有关Patchwork的更多信息，请参见http://jk.ozlabs.org/projects/patchwork/。
  Buildroot的Patchwork网站主要供Buildroot的维护者使用，以确保不会丢失补丁。 Buildroot修补程序审阅者也使用它（另请参阅第21.3.1节）。 但是，由于该网站在简洁明了的Web界面中公开了补丁及其相应的评论，因此它对所有Buildroot开发人员都是有用的。
  Buildroot修补程序管理界面可从http://patchwork.buildroot.org获得。

第二部分-用户指南

第6章 Buildroot配置

make * config中的所有配置选项都有一个帮助文本，其中提供有关该选项的详细信息。
make * config命令还提供了搜索工具。 阅读不同的前端菜单中的帮助消息以了解如何使用它：

• 在menuconfig中，通过按/调用搜索工具
• 在xconfig中，通过按Ctrl + f调用搜索工具

搜索结果显示匹配项的帮助消息。 在menuconfig中，左栏中的数字提供了相应条目的快捷方式。 只需键入此数字即可直接跳至该条目，或在由于缺少相关性而无法选择该条目的情况下跳至包含菜单。
尽管条目的菜单结构和帮助文本应该很容易解释，但是许多主题需要额外的说明，这些内容很难在帮助文本中介绍，因此在以下各节中进行介绍。

交叉编译工具链

编译工具链是允许您为系统编译代码的一组工具。 它由一个编译器（在我们的情况下为gcc），二进制utils（例如汇编程序和链接程序）（在我们的情况下为binutils）和一个C标准库（例如GNU Libc，uClibc-ng）组成。

开发工作站上安装的系统肯定已经具有一个编译工具链，可用于编译在系统上运行的应用程序。 如果您使用的是PC，则您的编译工具链可在x86处理器上运行，并为x86处理器生成代码。 在大多数Linux系统中，编译工具链使用GNU libc（glibc）作为C标准库。 该编译工具链称为“主机编译工具链”。 在其上运行并在其上工作的计算机称为“主机系统”。此术语不同于GNU configure所使用的术语，GNU configure所使用的主机是运行应用程序的计算机（通常与目标计算机相同）。

分发工具提供了编译工具链，并且Buildroot与它无关（除了使用它来构建交叉编译工具链和在开发主机上运行的其他工具之外）。

如上所述，系统随附的编译工具链可在其上运行并为主机系统中的处理器生成代码。 由于您的嵌入式系统具有不同的处理器，因此您需要交叉编译工具链-一种在您的主机系统上运行但为目标系统（和目标处理器）生成代码的编译工具链。 例如，如果您的主机系统使用x86，而目标系统使用ARM，则主机上的常规编译工具链在x86上运行并为x86生成代码，而交叉编译工具链在x86上运行并为ARM生成代码。

Buildroot为交叉编译工具链提供了两种解决方案：

• 内部工具链后端，在配置界面中称为Buildroot工具链。
• 外部工具链后端，在配置界面中称为“外部工具链”。

可以使用“工具链”菜单中的“工具链类型”选项在这两种解决方案之间进行选择。 选择一种解决方案后，将出现许多配置选项，以下各节将详细介绍这些选项。

内部工具链后端

内部工具链后端是Buildroot在构建目标嵌入式系统的用户空间应用程序和库之前，自行构建交叉编译工具链的后端。

该后端支持多个C库：uClibc-ng，glibc和musl。

选择此后端后，将显示许多选项。 最重要的允许：

• 更改用于构建工具链的Linux内核标头的版本。这个项目值得一些解释。在构建交叉编译工具链的过程中，正在构建C库。该库提供了用户空间应用程序和Linux内核之间的接口。为了知道如何与Linux内核“对话”，C库需要访问Linux内核头文件（即内核中的.h文件），这些头文件定义了用户空间和内核之间的接口（系统调用，数据结构等）。由于此接口是向后兼容的，因此用于构建工具链的Linux内核标头的版本不需要与打算在嵌入式系统上运行的Linux内核的版本完全匹配。他们只需要具有与要运行的Linux内核相同或更低的版本即可。如果使用的内核标头比嵌入式系统上运行的Linux内核更新，则C库可能正在使用Linux内核未提供的接口。
• 更改GCC编译器，binutils和C库的版本
• 选择许多工具链选项（仅uClibc）：工具链应具有RPC支持（主要用于NFS），宽字符支持，语言环境支持（用于国际化），C ++支持还是线程支持。 根据您选择的选项，在Buildroot菜单中可见的用户空间应用程序和库的数量将发生变化：许多应用程序和库需要启用某些工具链选项。 当需要某个工具链选项才能启用那些软件包时，大多数软件包都会显示注释。 如果需要，可以通过运行make uclibc-menuconfig进一步优化uClibc配置。 但是请注意，已针对Buildroot中捆绑的默认uClibc配置对Buildroot中的所有软件包进行了测试：如果通过从uClibc中删除功能而偏离此配置，则某些软件包可能不再生成。

值得注意的是，无论何时修改这些选项之一，都必须重建整个工具链和系统。 请参阅第8.2节。

值得注意的是，无论何时修改这些选项之一，都必须重建整个工具链和系统。 请参阅第8.2节。

该后端的优点：

• 与Buildroot良好集成
• 快速，仅构建必要的内容

该后端的缺点：

• 做清理时需要重建工具链，这需要时间。 如果您想减少构建时间，请考虑使用外部工具链后端。

外部工具链后端

外部工具链后端允许使用现有的预先构建的交叉编译工具链。 Buildroot知道许多著名的交叉编译工具链（来自ARM的Linaro，ARM的Sourcery CodeBench，x86-64，PowerPC和MIPS，并且能够自动下载它们，或者可以指向自定义工具链。 ，可以下载或在本地安装。

然后，您有三种使用外部工具链的解决方案：

• 使用预定义的外部工具链配置文件，并让Buildroot下载，提取和安装工具链。 Buildroot已经知道一些CodeSourcery和Linaro工具链。 只需从可用的工具链中选择工具链配置文件。 这绝对是最简单的解决方案。
• 使用预定义的外部工具链配置文件，而不是让Buildroot下载并解压缩工具链，而是可以告诉Buildroot您的工具链已在系统上安装的位置。 只需通过可用工具栏中的工具链中选择工具链配置文件，取消选择自动下载工具链，然后使用交叉编译工具链的路径填充工具链路径文本条目。
• 使用完全自定义的外部工具链。 这对于使用crosstool-NG或Buildroot本身生成的工具链特别有用。 为此，请在“工具链”列表中选择“自定义”工具链解决方案。 您需要填写工具链路径，工具链前缀和外部工具链C库选项。 然后，您必须告诉Buildroot您的外部工具链支持什么。 如果您的外部工具链使用glibc库，则只需告诉您工具链是否支持C ++，以及它是否具有内置的RPC支持。 如果您的外部工具链使用uClibc库，那么您必须告诉Buildroot它是否支持RPC，宽字符，语言环境，程序调用，线程和C ++。 在执行开始时，Buildroot会告诉您所选的选项是否与工具链配置不匹配。

我们的外部工具链支持已通过CodeSourcery和Linaro的工具链，crosstool NG生成的工具链以及Buildroot本身生成的工具链进行了测试。 通常，所有支持sysroot功能的工具链都应该起作用。 如果没有，请立即与开发人员联系。

我们不支持OpenEmbedded或Yocto生成的工具链或SDK，因为这些工具链不是纯工具链（即仅编译器，binutils，C和C ++库）。 相反，这些工具链带有大量预编译的库和程序。 因此，Buildroot无法导入工具链的sysroot，因为它将包含通常由Buildroot生成的数百兆字节的预编译库。

我们也不支持使用发行版工具链（即您的发行版中安装的gcc / binutils / C库）作为为目标构建软件的工具链。 这是因为您的分发工具链不是“纯”工具链（即仅使用C / C ++库），因此我们无法将其正确导入到Buildroot构建环境中。 因此，即使您正在为x86或x86_64目标构建系统，也必须使用Buildroot或crosstool NG生成交叉编译工具链。

如果要为您的项目生成自定义工具链，可以将其用作Buildroot中的外部工具链，则我们的建议绝对是使用crosstool-NG进行构建。 我们建议与Buildroot分开构建工具链，然后使用外部工具链后端将其导入Buildroot。

该后端的优点：

• 允许使用众所周知且经过测试的交叉编译工具链。
• 避免了交叉编译工具链的构建时间，这在嵌入式Linux系统的总体构建时间中通常非常重要。
  该后端的缺点：
• 如果您预先构建的外部工具链有错误，则可能很难从工具链供应商处获得修复，除非您自己使用Crosstool-NG来构建外部工具链。

外部工具链包装器

使用外部工具链时，Buildroot会生成包装程序，该程序将适当的选项（根据配置）透明地传递给外部工具链程序。 如果您需要调试此包装器以检查传递的参数是正确的，则可以将环境变量BR2_DEBUG_WRAPPER设置为以下任意一个：

• 0，为空或未设置：无调试
• 1：单行跟踪所有参数
• 2：每行跟踪一个参数

/ dev管理

在Linux系统上，/ dev目录包含称为设备文件的特殊文件，这些文件允许用户空间应用程序访问Linux内核管理的硬件设备。 没有这些设备文件，即使Linux内核正确识别了硬件设备，您的用户空间应用程序也将无法使用它们。 在系统配置/ dev管理下，Buildroot提供了四种不同的解决方案来处理/ dev目录：

• 第一个解决方案是使用设备表的静态。这是在Linux中处理设备文件的传统方法。使用这种方法，设备文件会永久存储在根文件系统中（即它们在重新引导后仍然存在），并且在从系统中添加或删除硬件设备时，没有什么东西会自动创建和删除这些设备文件。因此，Buildroot使用设备表创建一组标准的设备文件，默认文件存储在Buildroot源代码的system / device_table_dev.txt中。当Buildroot生成最终的根文件系统映像时，将处理此文件，因此在输出/目标目录中看不到设备文件。 BR2_ROOTFS_STATIC_DEVICE_TABLE选项允许更改Buildroot使用的默认设备表，或添加其他设备表，以便Buildroot在构建过程中创建其他设备文件。因此，如果您使用此方法，而系统中缺少设备文件，则可以例如创建包含其他设备文件描述的board / <yourcompany> / <yourproject> /device_table_dev.txt文件，然后您可以将BR2_ROOTFS_STATIC_DEVICE_TABLE设置为system / dev ice_table_dev.txt板/ <您的公司> / <您的项目> /device_table_dev.txt。有关设备表文件格式的更多详细信息，请参见第23章。

• 第二种解决方案是仅使用devtmpfs进行动态处理。 devtmpfs是Linux内核中的一个虚拟文件系统，已在内核2.6.32中引入（如果使用较旧的内核，则无法使用此选项）。 在/ dev中挂载时，此虚拟文件系统将自动使设备文件在添加和从系统中删除硬件设备时显示和消失。 该文件系统在重新启动后并不持久：它由内核动态填充。 使用devtmpfs要求启用以下内核配置选项：CONFIG_DEVTMPFS和CONFIG_DEVTMPFS_MOUNT。 当Buildroot负责为嵌入式设备构建Linux内核时，请确保启用了这两个选项。 但是，如果在Buildroot之外构建Linux内核，则有责任启用这两个选项（如果失败，则Buildroot系统将不会启动）。

• 第三种解决方案是使用devtmpfs + mdev进行动态处理。此方法还依赖于上面详述的devtmpfs虚拟文件系统（因此仍然需要在内核配置中启用CONFIG_DEVTMPFS和CONFIG_DEVTMPFS_MOUNT的要求），但是在其之上添加了mdev用户空间实用程序。 mdev是BusyBox的程序部分，内核在每次添加或删除设备时都会调用。借助/etc/mdev.conf配置文件，可以将mdev配置为例如在设备文件上设置特定的权限或所有权，在设备出现或消失时调用脚本或应用程序，等等。基本上，它允许用户空间执行以下操作：对设备添加和删除事件做出反应。例如，当设备出现在系统上时，可以使用mdev自动加载内核模块。如果您的设备需要固件，则mdev也很重要，因为它将负责将固件内容推送到内核。 mdev是udev的轻量级实现（功能较少）。有关mdev及其配置文件的语法的更多详细信息，请参见http://git.busybox.net/- busybox / tree / docs / mdev.txt。

• 第四个解决方案是使用devtmpfs + eudev进行动态处理。 此方法还依赖于上面详细介绍的devtmpfs虚拟文件系统，但在其上面添加了eudev用户空间守护程序。 eudev是一个后台运行的守护程序，当从系统中添加或删除设备时，内核会调用它。 与mdev相比，它是重量级的解决方案，但具有更高的灵活性。 eudev是udev的独立版本，udev是大多数桌面Linux发行版中使用的原始用户空间守护程序，现已成为Systemd的一部分。 有关更多详细信息，请参见http://en.wikipedia.org/wiki/Udev

Buildroot开发人员的建议是从仅使用devtmpfs的Dynamic解决方案开始，直到需要在添加/删除设备或需要固件时通知用户空间为止，在这种情况下，通常最好使用devtmpfs + mdev进行Dynamic处理。 解。

请注意，如果选择systemd作为初始化系统，则/ dev管理将由systemd提供的udev程序执行。
Buildroot开发人员的建议是从仅使用devtmpfs的Dynamic解决方案开始，直到需要在添加/删除设备或需要固件时通知用户空间为止，在这种情况下，通常最好使用devtmpfs + mdev进行Dynamic处理 ，请注意，如果选择systemd作为初始化系统，则/ dev管理将由systemd提供的udev程序执行。

初始化系统

init程序是内核启动的第一个用户空间程序（带有PID号1），它负责启动用户空间服务和程序（例如：Web服务器，图形应用程序，其他网络服务器等）。

Buildroot允许使用三种不同类型的初始化系统，可以从系统配置（初始化系统）中进行选择：

• 第一个解决方案是BusyBox。 在许多程序中，BusyBox都有一个基本的初始化程序的实现，对于大多数嵌入式系统而言，这已经足够了。 启用BR2_INIT_BUSYBOX将确保BusyBox将生成并安装其init程序。 这是Buildroot中的默认解决方案。 BusyBox初始化程序将在引导时读取/ etc / inittab文件，以了解操作方法。 可以在http://git.busybox.net/busybox/tree/examples/inittab中找到此文件的语法（请注意，BusyBox inittab语法很特殊：请勿使用Internet上的随机inittab文档来了解BusyBox inittab ）。 Buildroot中的默认inittab存储在system / skeleton / etc / inittab中。 除了安装一些重要的文件系统之外，默认的inittab的主要工作是启动/etc/init.d/rcS shell脚本，并启动一个getty程序（提供登录提示）。

• 第二种解决方案是systemV。 该解决方案使用旧的传统sysvinit程序，该程序打包在Buildroot中，位于package / sysvinit中。 这是大多数桌面Linux发行版中使用的解决方案，直到他们切换到更新的替代版本（如Upstart或Systemd）为止。 sysvinit也可用于inittab文件（其语法与BusyBox中的语法略有不同）。 随此init解决方案一起安装的默认inittab位于package / sysvinit / inittab中。

• 第三种解决方案是systemd。 systemd是用于Linux的新一代init系统。 它的功能远远超过传统的init程序：积极的并行化功能，使用套接字和D-Bus激活来启动服务，按需启动守护进程，使用Linux控制组跟踪进程，支持快照和恢复系统状态， systemd在相对复杂的嵌入式系统上很有用，例如需要D-Bus和服务之间相互通信的系统。 值得注意的是，systemd带来了大量的大型依赖项：dbus，udev等。 有关systemd的更多详细信息，请参见http://www.freedesktop.org/wiki/Software/systemd。

Buildroot开发人员推荐的解决方案是使用BusyBox初始化，因为它对于大多数嵌入式系统来说已经足够。 systemd可用于更复杂的情况。

第7章 其他组件的配置

在尝试修改下面的任何组件之前，请确保您已经配置了Buildroot本身，并启用了相应的软件包。

BusyBox
如果您已有BusyBox配置文件，则可以使用BR2_PACKAGE_BUSYBOX_CONFIG在Buildroot配置中直接指定此文件。 否则，Buildroot将从默认的BusyBox配置文件开始。 要对配置进行后续更改，请使用make busybox-menuconfig打开BusyBox配置编辑器。 也可以通过环境变量指定BusyBox配置文件，尽管不建议这样做。 有关更多详细信息，请参见第8.6节。

uClibc
uClibc的配置与BusyBox的配置相同。 用于指定现有配置文件的配置变量为BR2_UCLIBC_CONFIG。 进行后续更改的命令是make uclibc-menuconfig。

Linux内核
如果已经有了内核配置文件，则可以使用BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG在Buildroot配置中直接指定此文件。 如果您还没有内核配置文件，则可以使用BR2_LINUX_KERNEL_USE_DEFCONFIG在Buildroot配置中指定一个defconfig开始，或者使用BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG创建一个空文件并将其指定为自定义配置文件开始。 要对配置进行后续更改，请使用make linux-menuconfig打开Linux配置编辑器。

Barebox
Barebox的配置与Linux内核的配置相同。 相应的配置变量是BR2_TARGET_BAREBOX_USE_CUSTOM_CONFIG和BR2_TARGET_BAREBOX_USE_DEFCONFIG。 要打开配置编辑器，请使用make nudebox-menuconfig

U-Boot
U-Boot（版本2015.04或更高版本）的配置与Linux内核的配置相同。 相应的配置变量是BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG和BR2_TARGET_UBOOT_USE_DEFCONFIG。 要打开配置编辑器，请使用make uboot-menuconfig。

第8章 Buildroot的一般用法

make 的一些技巧

这是一系列技巧，可帮助您充分利用Buildroot。
显示make执行的所有命令：

$ make V=1 <target>

显示带有defconfig的板列表：

$ make list-defconfigs

显示所有可用的目标：

$ make help

并非所有目标都始终可用，.config文件中的某些设置可能会隐藏一些目标：

• busybox-menuconfig仅在启用busybox时有效；
• linux-menuconfig和linux-savedefconfig仅在启用linux时起作用；
• 仅当在内部工具链后端中选择了uClibc C库时，uclibc-menuconfig才可用。
• 仅在启用了裸箱引导加载程序时，beardbox-menuconfig和beardbox-savedefconfig才起作用。
• uboot-menuconfig和uboot-savedefconfig仅在启用U-Boot引导加载程序时起作用。

清理：更改任何体系结构或工具链配置选项时，都需要显式清洁。 要删除所有构建产品（包括构建目录，主机，暂存和目标树，映像和工具链）：

$ make clean

**生成手册：**当前的手册源位于docs / manual目录中。 生成手册：

$ make manual-clean
$ make manual

手动输出将在output / docs / manual中生成。
注意：需要一些工具来构建文档（请参阅：2.2节）

为新目标重置Buildroot：删除所有构建产品和配置：

$ make distclean

注意如果启用了ccache，则运行make clean或distclean不会清空Buildroot使用的编译器缓存。 要删除它，请参阅第8.12.3节。

转储内部make变量：可以转储已知的所有make变量及其值：

$ make -s printvars
VARIABLE=value_of_variable
…

可以使用一些变量来调整输出：

• VARS会将列表限制为名称与指定的make-pattern匹配的变量
• QUOTED_VARS（如果设置为YES）将单引号
• RAW_VARS（如果设置为YES）将打印未扩展的值

例如：

$ make -s printvars VARS=BUSYBOX_%DEPENDENCIES
BUSYBOX_DEPENDENCIES=skeleton toolchain
BUSYBOX_FINAL_ALL_DEPENDENCIES=skeleton toolchain
BUSYBOX_FINAL_DEPENDENCIES=skeleton toolchain
BUSYBOX_FINAL_PATCH_DEPENDENCIES=
BUSYBOX_RDEPENDENCIES=ncurses util-linux

$ make -s printvars VARS=BUSYBOX_%DEPENDENCIES QUOTED_VARS=YES
BUSYBOX_DEPENDENCIES='skeleton toolchain'
BUSYBOX_FINAL_ALL_DEPENDENCIES='skeleton toolchain'
BUSYBOX_FINAL_DEPENDENCIES='skeleton toolchain'
BUSYBOX_FINAL_PATCH_DEPENDENCIES=''
BUSYBOX_RDEPENDENCIES='ncurses util-linux'

$ make -s printvars VARS=BUSYBOX_%DEPENDENCIES RAW_VARS=YES
BUSYBOX_DEPENDENCIES=skeleton toolchain
BUSYBOX_FINAL_ALL_DEPENDENCIES=$(sort $(BUSYBOX_FINAL_DEPENDENCIES) $(BUSYBOX_FINAL_PATCH_DEPENDENCIES))
BUSYBOX_FINAL_DEPENDENCIES=$(sort $(BUSYBOX_DEPENDENCIES))
BUSYBOX_FINAL_PATCH_DEPENDENCIES=$(sort $(BUSYBOX_PATCH_DEPENDENCIES))
BUSYBOX_RDEPENDENCIES=ncurses util-linux

带引号的变量的输出可以在shell脚本中重用，例如：

$ eval $(make -s printvars VARS=BUSYBOX_DEPENDENCIES QUOTED_VARS=YES) 
$ echo $BUSYBOX_DEPENDENCIES 
skeleton toolchain

了解何时需要完全重建

当通过make menuconfig，make xconfig或其他配置工具之一更改系统配置时，Buildroot不会尝试检测应重建系统的哪些部分。 在某些情况下，Buildroot应该重建整个系统，在某些情况下，仅应重建软件包的特定子集。 但是以完全可靠的方式检测到这一点非常困难，因此Buildroot开发人员已决定不尝试这样做。

相反，用户有责任知道何时需要完全重建。 作为提示，这里有一些经验法则可以帮助您了解如何使用Buildroot：

• 更改目标体系结构配置时，需要完全重建。 例如，更改体系结构变体，二进制格式或浮点策略会对整个系统产生影响。
• 更改工具链配置时，通常需要完全重建。 更改工具链配置通常涉及更改编译器版本，C库的类型或其配置或其他一些基本配置项，这些更改会影响整个系统。
• 将其他程序包添加到配置时，不一定需要完全重建。 Buildroot将检测到此软件包从未构建过，并将对其进行构建。 但是，如果此程序包是可以选择供已构建的程序包使用的库，则Buildroot将不会自动重建它们。 您或者知道应该重建哪些软件包，或者可以手动重建它们，或者应该进行完全重建。 例如，假设您使用ctorrent软件包构建了一个系统，但没有openssl。 您的系统可以运行，但是您意识到要在ctorrent中获得SSL支持，因此在Buildroot配置中启用openssl软件包并重新启动构建。 Buildroot将检测到应该构建并构建openssl，但是它不会检测到应该重新构建ctorrent以从openssl中受益，以添加OpenSSL支持。 您将必须进行完全重建，或重建ctorrent本身
• 从配置中删除软件包时，Buildroot不会执行任何特殊操作。 它不会从目标根文件系统或工具链sysroot中删除此软件包安装的文件。 需要完全重建才能摆脱此软件包。 但是，通常您不必立即删除此软件包：您可以等待下一个午餐时间以从头开始重新构建。
• 更改软件包的子选项时&