Using Buildroot =============== Configuration and general usage ------------------------------- Buildroot has a nice configuration tool similar to the one you can find in the http://www.kernel.org/[Linux kernel] or in http://www.busybox.net/[Busybox]. Note that you can (and should) build everything as a normal user. There is no need to be root to configure and use Buildroot. The first step is to run the configuration assistant: -------------------- $ make menuconfig -------------------- to run the curses-based configurator, or -------------------- $ make xconfig -------------------- or -------------------- $ make gconfig -------------------- to run the Qt or GTK-based configurators. All of these "make" commands will need to build a configuration utility, so you may need to install "development" packages for relevant libraries used by the configuration utilities. On Debian-like systems, the +libncurses5-dev+ package is required to use the 'menuconfig' interface, +libqt4-dev+ is required to use the 'xconfig' interface, and +libglib2.0-dev, libgtk2.0-dev and libglade2-dev+ are needed to use the 'gconfig' interface. For each menu entry in the configuration tool, you can find associated help that describes the purpose of the entry. Once everything is configured, the configuration tool generates a +.config+ file that contains the description of your configuration. It will be used by the Makefiles to do what's needed. Let's go: -------------------- $ make -------------------- You *should never* use +make -jN+ with Buildroot: it does not support 'top-level parallel make'. Instead, use the +BR2_JLEVEL+ option to tell Buildroot to run each package compilation with +make -jN+. This command will generally perform the following steps: * Download source files (as required) * Configure, build and install the cross-compiling toolchain if an internal toolchain is used, or import a toolchain if an external toolchain is used * Build/install selected target packages * Build a kernel image, if selected * Build a bootloader image, if selected * Create a root filesystem in selected formats Buildroot output is stored in a single directory, +output/+. This directory contains several subdirectories: * +images/+ where all the images (kernel image, bootloader and root filesystem images) are stored. * +build/+ where all the components except for the cross-compilation toolchain are built (this includes tools needed to run Buildroot on the host and packages compiled for the target). The +build/+ directory contains one subdirectory for each of these components. * +staging/+ which contains a hierarchy similar to a root filesystem hierarchy. This directory contains the installation of the cross-compilation toolchain and all the userspace packages selected for the target. However, this directory is 'not' intended to be the root filesystem for the target: it contains a lot of development files, unstripped binaries and libraries that make it far too big for an embedded system. These development files are used to compile libraries and applications for the target that depend on other libraries. * +target/+ which contains 'almost' the complete root filesystem for the target: everything needed is present except the device files in +/dev/+ (Buildroot can't create them because Buildroot doesn't run as root and doesn't want to run as root). Therefore, this directory *should not be used on your target*. Instead, you should use one of the images built in the +images/+ directory. If you need an extracted image of the root filesystem for booting over NFS, then use the tarball image generated in +images/+ and extract it as root. Compared to +staging/+, +target/+ contains only the files and libraries needed to run the selected target applications: the development files (headers, etc.) are not present, unless the +development files in target filesystem+ option is selected. * +host/+ contains the installation of tools compiled for the host that are needed for the proper execution of Buildroot, including the cross-compilation toolchain. * +toolchain/+ contains the build directories for the various components of the cross-compilation toolchain. Offline builds -------------- If you intend to do an offline build and just want to download all sources that you previously selected in the configurator ('menuconfig', 'xconfig' or 'gconfig'), then issue: -------------------- $ make source -------------------- You can now disconnect or copy the content of your +dl+ directory to the build-host. Building out-of-tree -------------------- Buildroot supports building out of tree with a syntax similar to the Linux kernel. To use it, add +O=+ to the make command line: -------------------- $ make O=/tmp/build -------------------- Or: -------------------- $ cd /tmp/build; make O=$PWD -C path/to/buildroot -------------------- All the output files will be located under +/tmp/build+. When using out-of-tree builds, the Buildroot +.config+ and temporary files are also stored in the output directory. This means that you can safely run multiple builds in parallel using the same source tree as long as they use unique output directories. For ease of use, Buildroot generates a Makefile wrapper in the output directory - So after the first run, you no longer need to pass +O=..+ and +-C ..+, simply run (in the output directory): -------------------- $ make -------------------- Environment variables --------------------- [[env-vars]] Buildroot also honors some environment variables, when they are passed to +make+ or set in the environment: * +HOSTCXX+, the host C++ compiler to use * +HOSTCC+, the host C compiler to use * +UCLIBC_CONFIG_FILE=+, path to the uClibc configuration file, used to compile uClibc, if an internal toolchain is being built * +BUSYBOX_CONFIG_FILE=+, path to the Busybox configuration file * +BUILDROOT_DL_DIR+ to override the directory in which Buildroot stores/retrieves downloaded files An example that uses config files located in the toplevel directory and in your $HOME: -------------------- $ make UCLIBC_CONFIG_FILE=uClibc.config BUSYBOX_CONFIG_FILE=$HOME/bb.config -------------------- If you want to use a compiler other than the default +gcc+ or +g+++ for building helper-binaries on your host, then do -------------------- $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD -------------------- Complying with opensource licenses ---------------------------------- [[legal-info]] All of the end products of Buildroot (toolchain, root filesystem, kernel, bootloaders) contain opensource software, released under various licenses. Using opensource software gives you the freedom to build rich embedded systems choosing from a wide range of packages, but also gives some obligations that you must know and honour. Some licenses require you to publish the license text in the documentation of your product. Other require you to redistribute the source code of the software to those that receive your product. The exact requirements of each license is documented in each package, and it is your (or your legal office's) responsibility to comply with these requirements. To make this easier for you, Buildroot can collect for you some material you will probably need. To produce this material, after you configured Buildroot with +make menuconfig+, +make xconfig+ or +make gconfig+, run: -------------------- make legal-info -------------------- Buildroot will collect legally-relevant material in your output directory, under the +legal-info/+ subdirectory. There you will find: * A +README+ file, that summarizes the produced material and contains warnings about material that Buildroot could not produce. * +buildroot.config+: this is the Buildroot configuration file that is usually produced with +make menuconfig+, and which is necessary to reproduce the build. * The source code for all packages; this is saved in the +sources/+ subdirectory (except for proprietary packages, whose source code is not saved); patches applied to some packages by Buildroot are distributed with the Buildroot sources and are not duplicated in the +sources/+ subdirectory. * A manifest file listing the configured packages, their version, license and related information. Some of these information might be not defined in Buildroot; in this case they are clearly marked as "unknown" or similar. * A +licenses/+ subdirectory, which contains the license text of packages. If the license file(s) are not defined in Buildroot, the file is not produced and a warning in the +README+ indicates this. Please note that the aim of the +legal-info+ feature of Buildroot is to produce all the material that is somehow relevant for legal compliance with the package licenses. Buildroot does not try to produce the exact material that you must somehow make public. It does surely produce some more material than is needed for a strict legal compliance. For example, it produces the source code for packages released under BSD-like licenses, that you might not want to redistribute in source form. Moreover, due to technical limitations, Buildroot does not produce some material that you will or may need, such as the toolchain source code and the Buildroot source code itself. When you run +make legal-info+, Buildroot produces warnings in the +README+ file to inform you of relevant material that could not be saved. Here is a list of the licenses that are most widely used by packages in Buildroot, with the name used in the manifest file: * +GPLv2+: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[ GNU General Public License, version 2]; * +GPLv2++: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[ GNU General Public License, version 2] or (at your option) any later version; * +GPLv3+: http://www.gnu.org/licenses/gpl.html[ GNU General Public License, version 3]; * +GPLv3++: http://www.gnu.org/licenses/gpl.html[ GNU General Public License, version 3] or (at your option) any later version; * +GPL+: http://www.gnu.org/licenses/gpl.html[ GNU General Public License] (any version); * +LGPLv2.1+: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html[ GNU Lesser General Public License, version 2.1]; * +LGPLv2.1++: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html[ GNU Lesser General Public License, version 2.1] or (at your option) any later version; * +LGPLv3+: http://www.gnu.org/licenses/lgpl.html[ GNU Lesser General Public License, version 3]; * +LGPLv3++: http://www.gnu.org/licenses/lgpl.html[ GNU Lesser General Public License, version 3] or (at your option) any later version; * +LGPL+: http://www.gnu.org/licenses/lgpl.html[ GNU Lesser General Public License] (any version); * +BSD-4c+: Original BSD 4-clause license; * +BSD-3c+: BSD 3-clause license; * +BSD-2c+: BSD 2-clause license; * +PROPRIETARY+: marks a non-opensource package; Buildroot does not save any licensing info or source code for these packages. Complying with the Buildroot license ------------------------------------ Buildroot itself is an opensource software, released under the http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[GNU General Public License, version 2] or (at your option) any later version. However, being a build system, it is not normally part of the end product: if you develop the root filesystem, kernel, bootloader or toolchain for a device, the code of Buildroot is only present on the development machine, not in the device storage. Nevertheless, the general view of the Buildroot developers is that you should release the Buildroot source code along with the source code of other packages when releasing a product that contains GPL-licensed software. This is because the http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[GNU GPL] defines the "'complete source code'" for an executable work as "'all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable'". Buildroot is part of the 'scripts used to control compilation and installation of the executable', and as such it is considered part of the material that must be redistributed. Keep in mind this is only the Buildroot developers' opinion, and you should consult your legal department or lawyer in case of any doubt.