# Building a BusyBox-Based System - Linux Embedded systems

Creating a system with BusyBox isn’t that much different than building any other open source project; in fact, the project uses some of the same build infrastructure and practices as the Linux kernel project.

Like the kernel, BusyBox has a menu-based configuration step where you can control how the application is built, followed by a build step that creates the binary. BusyBox also has an installation step that creates a minimal root file system containing all the symlinks for applications built into the BusyBox executable. The basic outline for building BusyBox is as follows:

1. Download the software. You can fetch BusyBox in a tar file, or you can access the Git repository. The Git repository always contains the most recent version of the code, and the tar files contain development snapshots. In general, as with any embedded project, the tar files are more stable than the code fresh from the developers.
2. Configure. This step allows you to specify the configuration parameters for the build and what applets are included in the BusyBox binary file. The configuration tool is the same as the tool used for the Linux kernel, so the interface and workings should be familiar.
3. Build. This step is uninteresting because the configuration work already been done. Here, you just need to tell the make file what cross-compiler to use and wait for the process to finish.
4. Install. This step creates a directory with the applets and the BusyBox executable. There’s some additional work to do in order to get a complete system so you can test whether the build boots on the board.

As an example, you’ll use the 1.14.1 release on this page, but understand that the release will be different by the time this makes it to press:  tar xjf busybox-1.14.1.tar.bz2

At this point, the busybox-1.14.1 directory has the sources for BusyBox ready for compilation. The source is also available using Git, by doing the following:

This creates a clone of the Git repository in the directory ./busybox. The Git clone process takes a few minutes, even with a fast Internet connection. If you want to follow a certain branch of BusyBox, use this command to fetch the changes for the branch

where <branch> is the version of BusyBox. In this example, using 14 for the branch fetches the changes for the 1.14.x line of development:

You should run these commands from the directory containing the Git repository; in this example, it’s ./busybox. Following a branch makes sense when you want to get just the minor changes for a release and not larger-scale changes that may affect your project.

Configure

BusyBox must be configured before being built. In the configuration process, you specify what applets to compile and how to build the project. The system used is the same as the Linux kernel, so when you do the following $make; enuconfig you see a very familiar interface. When you’re running the configuration for the first time, no applets have been selected, meaning the root file system doesn’t have anything to run. This is probably not you want. Selecting a minimal set of applets requires much tedious clicking, even after you know what constitutes a minimum set of applets. In order to get a set of applets approximating what would be on a desktop system, do the following:$ make defconfig

The configuration process shows how it’s configured by producing the following output:
(output clipped)

The default configuration isn’t the smallest configuration. It contains nearly all of the applets, but it’s the fastest and easiest way to get started. When you need to economize on space, you can reduce the number of applets to what your system needs, but that’s a matter of economization.