Chapter 5. Going further in Buildroot’s innards

5.1. How Buildroot works

As mentioned above, Buildroot is basically a set of Makefiles that download, configure, and compile software with the correct options. It also includes patches for various software packages - mainly the ones involved in the cross-compilation toolchain (gcc, binutils and uClibc).

There is basically one Makefile per software package, and they are named with the .mk extension. Makefiles are split into many different parts.

  • The toolchain/ directory contains the Makefiles and associated files for all software related to the cross-compilation toolchain: binutils, gcc, gdb, kernel-headers and uClibc.
  • The arch/ directory contains the definitions for all the processor architectures that are supported by Buildroot.
  • The package/ directory contains the Makefiles and associated files for all user-space tools and libraries that Buildroot can compile and add to the target root filesystem. There is one sub-directory per package.
  • The linux/ directory contains the Makefiles and associated files for the Linux kernel.
  • The boot/ directory contains the Makefiles and associated files for the bootloaders supported by Buildroot.
  • The system/ directory contains support for system integration, e.g. the target filesystem skeleton and the selection of an init system.
  • The fs/ directory contains the Makefiles and associated files for software related to the generation of the target root filesystem image.

Each directory contains at least 2 files:

  • is the Makefile that downloads, configures, compiles and installs the package something.
  • is a part of the configuration tool description file. It describes the options related to the package.

The main Makefile performs the following steps (once the configuration is done):

  • Create all the output directories: staging, target, build, stamps, etc. in the output directory (output/ by default, another value can be specified using O=)
  • Generate all the targets listed in the BASE_TARGETS variable. When an internal toolchain is used, this means generating the cross-compilation toolchain. When an external toolchain is used, this means checking the features of the external toolchain and importing it into the Buildroot environment.
  • Generate all the targets listed in the TARGETS variable. This variable is filled by all the individual components' Makefiles. Generating these targets will trigger the compilation of the userspace packages (libraries, programs), the kernel, the bootloader and the generation of the root filesystem images, depending on the configuration.

5.2. Advanced usage

5.2.1. Using the generated toolchain outside Buildroot

You may want to compile, for your target, your own programs or other software that are not packaged in Buildroot. In order to do this you can use the toolchain that was generated by Buildroot.

The toolchain generated by Buildroot is located by default in output/host/. The simplest way to use it is to add output/host/usr/bin/ to your PATH environment variable and then to use ARCH-linux-gcc, ARCH-linux-objdump, ARCH-linux-ld, etc.

It is possible to relocate the toolchain - but then --sysroot must be passed every time the compiler is called to tell where the libraries and header files are.

It is also possible to generate the Buildroot toolchain in a directory other than output/host by using the Build options → Host dir option. This could be useful if the toolchain must be shared with other users.

5.2.2. Using ccache in Buildroot

ccache is a compiler cache. It stores the object files resulting from each compilation process, and is able to skip future compilation of the same source file (with same compiler and same arguments) by using the pre-existing object files. When doing almost identical builds from scratch a number of times, it can nicely speed up the build process.

ccache support is integrated in Buildroot. You just have to enable Enable compiler cache in Build options. This will automatically build ccache and use it for every host and target compilation.

The cache is located in $HOME/.buildroot-ccache. It is stored outside of Buildroot output directory so that it can be shared by separate Buildroot builds. If you want to get rid of the cache, simply remove this directory.

You can get statistics on the cache (its size, number of hits, misses, etc.) by running make ccache-stats.

5.2.3. Location of downloaded packages

The various tarballs that are downloaded by Buildroot are all stored in BR2_DL_DIR, which by default is the dl directory. If you want to keep a complete version of Buildroot which is known to be working with the associated tarballs, you can make a copy of this directory. This will allow you to regenerate the toolchain and the target filesystem with exactly the same versions.

If you maintain several Buildroot trees, it might be better to have a shared download location. This can be achieved by pointing the BUILDROOT_DL_DIR environment variable to a directory. If this is set, then the value of BR2_DL_DIR in the Buildroot configuration is overridden. The following line should be added to <~/.bashrc>.

 $ export BUILDROOT_DL_DIR <shared download location>

The download location can also be set in the .config file, with the BR2_DL_DIR option. This value is overridden by the BUILDROOT_DL_DIR environment variable.

5.2.4. Package-specific make targets

Running make <package> builds and installs that particular package and its dependencies.

For packages relying on the Buildroot infrastructure, there are numerous special make targets that can be called independently like this:

make <package>-<target>

The package build targets are (in the order they are executed):

command/target Description


Fetch the source (download the tarball, clone the source repository, etc)


Build and install all dependencies required to build the package


Put the source in the package build directory (extract the tarball, copy the source, etc)


Apply the patches, if any


Run the configure commands, if any


Run the compilation commands


target package: Run the installation of the package in the staging directory, if necessary


target package: Run the installation of the package in the target directory, if necessary


target package: Run the 2 previous installation commands

host package: Run the installation of the package in the host directory

Additionally, there are some other useful make targets:

command/target Description


Displays the dependencies required to build the package


Run the clean command of the package, also uninstall the package from both the target and the staging directory; note that this is not implemented for all packages


Remove the whole package build directory


Re-run the compilation commands - this only makes sense when using the OVERRIDE_SRCDIR feature or when you modified a file directly in the build directory


Re-run the configure commands, then rebuild - this only makes sense when using the OVERRIDE_SRCDIR feature or when you modified a file directly in the build directory