Table of Contents
Config.in
file.mk
fileBuildroot usage and documentation by Thomas Petazzoni. Contributions from Karsten Kruse, Ned Ludd, Martin Herren and others.
Buildroot 2013.05 manual generated on 2013-05-31 22:39:05 CEST from git revision 615fd9b
Buildroot is a tool that simplifies and automates the process of building a complete Linux system for an embedded system, using cross-compilation.
In order to achieve this, Buildroot is able to generate a cross-compilation toolchain, a root filesystem, a Linux kernel image and a bootloader for your target. Buildroot can be used for any combination of these options, independently (you can for example use an existing cross-compilation toolchain, and build only your root filesystem with Buildroot).
Buildroot is useful mainly for people working with embedded systems. Embedded systems often use processors that are not the regular x86 processors everyone is used to having in his PC. They can be PowerPC processors, MIPS processors, ARM processors, etc.
Buildroot supports numerous processors and their variants; it also comes with default configurations for several boards available off-the-shelf. Besides this, a number of third-party projects are based on, or develop their BSP [1] or SDK [2] on top of Buildroot.
Buildroot is designed to run on Linux systems.
Buildroot needs some software to be already installed on the host system; here are the lists of the mandatory and optional packages (package names may vary between distributions).
Take care to install both runtime and development data, especially for the libraries that may be packaged in 2 distinct packages.
Build tools:
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
tar
cpio
python
(version 2.6 or 2.7)
unzip
rsync
Source fetching tools:
wget
Source fetching tools:
In the official tree, most of the package sources are retrieved
using wget
; a few are only available through their git
, mercurial
,
or svn
repository.
All other source fetching methods are implemented and may be used in a development context (further details: refer to Section 6.4, “Download infrastructure”).
bazaar
cvs
git
mercurial
rsync
scp
subversion
Configuration interface dependencies (requires development libraries):
ncurses5
to use the menuconfig interface
qt4
to use the xconfig interface
glib2
, gtk2
and glade2
to use the gconfig interface
Java-related packages, if the Java Classpath needs to be built for the target system:
javac
compiler
jar
tool
Documentation generation tools:
asciidoc
Buildroot releases are made approximately every 3 months. Direct Git access and daily snapshots are also available, if you want more bleeding edge.
Releases are available at http://buildroot.net/downloads/.
The latest snapshot is always available at http://buildroot.net/downloads/snapshots/buildroot-snapshot.tar.bz2, and previous snapshots are also available at http://buildroot.net/downloads/snapshots/.
To download Buildroot using Git, you can simply follow the rules described on the "Accessing Git" page (http://buildroot.net/git.html) of the Buildroot website (http://buildroot.net). For the impatient, here’s a quick recipe:
$ git clone git://git.buildroot.net/buildroot
Buildroot has a nice configuration tool similar to the one you can find in the Linux kernel or in 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 (including the interface), so you may need to install "development" packages for relevant libraries used by the configuration utilities. Check Section 2.1, “System requirements” to know what Buildroot needs, and specifically the optional requirements Section 2.1.2, “Optional packages” to get the dependencies of your favorite 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
.
The make
command will generally perform the following steps:
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). Also, it doesn’t have the correct
permissions (e.g. setuid for the busybox binary). 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, the binaries are
stripped.
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.
These commands, make menuconfig|gconfig|xconfig
and make
, are the
basic ones that allow to easily and quickly generate images fitting
your needs, with all the supports and applications you enabled.
More details about the "make" command usage are given in Section 3.2, “make tips”.
This section explains how you can customize Buildroot to fit your needs.
All the configuration options in make *config
have a help text
providing details about the option. However, a number of topics
require additional details that cannot easily be covered in the help
text and are there covered in the following sections.
A compilation toolchain is the set of tools that allows you to compile
code for your system. It consists of a compiler (in our case, gcc
),
binary utils like assembler and linker (in our case, binutils
) and a
C standard library (for example
GNU Libc,
uClibc).
The system installed on your development station certainly already has a compilation toolchain that you can use to compile an application that runs on your system. If you’re using a PC, your compilation toolchain runs on an x86 processor and generates code for an x86 processor. Under most Linux systems, the compilation toolchain uses the GNU libc (glibc) as the C standard library. This compilation toolchain is called the "host compilation toolchain". The machine on which it is running, and on which you’re working, is called the "host system" [3].
The compilation toolchain is provided by your distribution, and Buildroot has nothing to do with it (other than using it to build a cross-compilation toolchain and other tools that are run on the development host).
As said above, the compilation toolchain that comes with your system runs on and generates code for the processor in your host system. As your embedded system has a different processor, you need a cross-compilation toolchain - a compilation toolchain that runs on your host system but generates code for your target system (and target processor). For example, if your host system uses x86 and your target system uses ARM, the regular compilation toolchain on your host runs on x86 and generates code for x86, while the cross-compilation toolchain runs on x86 and generates code for ARM.
Buildroot provides different solutions to build, or use existing cross-compilation toolchains:
Buildroot toolchain
in
the configuration interface.
External toolchain
in
the configuration interface.
Crosstool-NG
toolchain
in the configuration interface.
The choice between these three solutions is done using the Toolchain
Type
option in the Toolchain
menu. Once one solution has been
chosen, a number of configuration options appear, they are detailed in
the following sections.
The internal toolchain backend is the backend where Buildroot builds by itself a cross-compilation toolchain, before building the userspace applications and libraries for your target embedded system.
This backend is the historical backend of Buildroot, and is limited to the usage of the uClibc C library (i.e, the glibc and eglibc C libraries are not supported by this backend, see the External toolchain backend and Crosstool-NG toolchain backend for solutions to use either glibc or eglibc).
Once you have selected this backend, a number of options appear. The most important ones allow to:
.h
files from the kernel), which
define the interface between userspace and the kernel (system
calls, data structures, etc.). Since this interface is backward
compatible, the version of the Linux kernel headers used to build
your toolchain do not need to match exactly the version of the
Linux kernel you intend to run on your embedded system. They only
need to have a version equal or older to the version of the Linux
kernel you intend to run. If you use kernel headers that are more
recent than the Linux kernel you run on your embedded system, then
the C library might be using interfaces that are not provided by
your Linux kernel.
make uclibc-menuconfig
command to get access to uClibc’s configuration interface. Note
that all packages in Buildroot are tested against the default
uClibc configuration bundled in Buildroot: if you deviate from this
configuration by removing features from uClibc, some packages may
no longer build.
It is worth noting that whenever one of those options is modified, then the entire toolchain and system must be rebuilt. See Section 3.5.1, “Understanding when a full rebuild is necessary”.
Advantages of this backend:
Drawbacks of this backend:
make clean
, which
takes time. If you’re trying to reduce your build time, consider
using the External toolchain backend.
The external toolchain backend allows to use existing pre-built cross-compilation toolchains. Buildroot knows about a number of well-known cross-compilation toolchains (from Linaro for ARM, Sourcery CodeBench for ARM, x86, x86-64, PowerPC, MIPS and SuperH, Blackfin toolchains from ADI, Xilinx toolchains for Microblaze, etc.) and is capable of downloading them automatically, or it can be pointed to a custom toolchain, either available for download or installed locally.
Then, you have three solutions to use an external toolchain:
Toolchain
from the
available ones. This is definitely the easiest solution.
Toolchain
through the available
ones, unselect Download toolchain automatically
, and fill the
Toolchain path
text entry with the path to your cross-compiling
toolchain.
Custom toolchain
solution in the Toolchain
list. You
need to fill the Toolchain path
, Toolchain prefix
and External
toolchain C library
options. Then, you have to tell Buildroot what
your external toolchain supports. If your external toolchain uses
the glibc library, you only have to tell whether your toolchain
supports C+\+ or not and whether it has built-in RPC support. If
your external toolchain uses the uClibc
library, then you have to tell Buildroot if it supports largefile,
IPv6, RPC, wide-char, locale, program invocation, threads and
C++. At the beginning of the execution, Buildroot will tell you if
the selected options do not match the toolchain configuration.
Our external toolchain support has been tested with toolchains from CodeSourcery and Linaro, toolchains generated by crosstool-NG, and toolchains generated by Buildroot itself. In general, all toolchains that support the sysroot feature should work. If not, do not hesitate to contact the developers.
We do not support toolchains from the ELDK of Denx, for two reasons:
CROSS_COMPILE
environment variable. This non-standard behaviour
makes it difficult to support ELDK in Buildroot.
We also do not support using the distribution toolchain (i.e the gcc/binutils/C library installed by your distribution) as the toolchain to build software for the target. This is because your distribution toolchain is not a "pure" toolchain (i.e only with the C/C++ library), so we cannot import it properly into the Buildroot build environment. So even if you are building a system for a x86 or x86_64 target, you have to generate a cross-compilation toolchain with Buildroot or crosstool-NG.
If you want to generate a custom toolchain for your project, that can be used as an external toolchain in Buildroot, our recommandation is definitely to build it with crosstool-NG. We recommend to build the toolchain separately from Buildroot, and then import it in Buildroot using the external toolchain backend.
Advantages of this backend:
Drawbacks of this backend:
The Crosstool-NG toolchain backend integrates the Crosstool-NG project with Buildroot. Crosstool-NG is a highly-configurable, versatile and well-maintained tool to build cross-compilation toolchains.
If you select the Crosstool-NG toolchain
option in Toolchain Type
,
then you will be offered to:
make
ctng-menuconfig
to get access to the Crosstool-NG configuration
interface. However, note that all Buildroot packages have only been
tested with the default Crosstool-NG configurations.
When you will start the Buildroot build process, Buildroot will download and install the Crosstool-NG tool, build and install its required dependencies, and then run Crosstool-NG with the provided configuration.
Advantages of this backend:
Drawbacks of this backend:
make
source
will not download all the source code tarballs needed by
Crosstool-NG).
make
clean
.
On a Linux system, the /dev
directory contains special files, called
device files, that allow userspace applications to access the
hardware devices managed by the Linux kernel. Without these device
files, your userspace applications would not be able to use the
hardware devices, even if they are properly recognized by the Linux
kernel.
Under System configuration
, /dev management
, Buildroot offers four
different solutions to handle the /dev
directory :
system/device_table_dev.txt
in the
Buildroot source code. This file is processed when Buildroot
generates the final root filesystem image, and the device files
are therefore not visible in the output/target
directory. The
BR2_ROOTFS_STATIC_DEVICE_TABLE
option allows to change the
default device table used by Buildroot, or to add an additional
device table, so that additional device files are created by
Buildroot during the build. So, if you use this method, and a
device file is missing in your system, you can for example create
a board/<yourcompany>/<yourproject>/device_table_dev.txt
file
that contains the description of your additional device files,
and then you can set BR2_ROOTFS_STATIC_DEVICE_TABLE
to
system/device_table_dev.txt
board/<yourcompany>/<yourproject>/device_table_dev.txt
. For more
details about the format of the device table file, see
Section 11.1, “Makedev syntax documentation”.
/dev
, this virtual
filesystem will automatically make device files appear and
disappear as hardware devices are added and removed from the
system. This filesystem is not persistent accross reboots: it is
filled dynamically by the kernel. Using devtmpfs requires the
following kernel configuration options to be enabled:
CONFIG_DEVTMPFS
and CONFIG_DEVTMPFS_MOUNT
. When Buildroot is in
charge of building the Linux kernel for your embedded device, it
makes sure that those two options are enabled. However, if you
build your Linux kernel outside of Buildroot, then it is your
responsability to enable those two options (if you fail to do so,
your Buildroot system will not boot).
CONFIG_DEVTMPFS
and CONFIG_DEVTMPFS_MOUNT
enabled in the kernel configuration still apply), but adds the
mdev
userspace utility on top of it. mdev
is a program part of
Busybox that the kernel will call every time a device is added or
removed. Thanks to the /etc/mdev.conf
configuration file, mdev
can be configured to for example, set specific permissions or
ownership on a device file, call a script or application whenever a
device appears or disappear, etc. Basically, it allows userspace
to react on device addition and removal events. mdev
can for
example be used to automatically load kernel modules when devices
appear on the system. mdev
is also important if you have devices
that require a firmware, as it will be responsible for pushing the
firmware contents to the kernel. mdev
is a lightweight
implementation (with fewer features) of udev
. For more details
about mdev
and the syntax of its configuration file, see
http://git.busybox.net/busybox/tree/docs/mdev.txt.
udev
userspace daemon on top of it. udev
is a daemon
that runs in the background, and gets called by the kernel when a
device gets added or removed from the system. It is a more
heavyweight solution than mdev
, but provides higher flexibility
and is sometimes mandatory for some system components (systemd for
example). udev
is the mechanism used in most desktop Linux
distributions. For more details about udev
, see
http://en.wikipedia.org/wiki/Udev.
The Buildroot developers recommandation is to start with the Dynamic using devtmpfs only solution, until you have the need for userspace to be notified when devices are added/removed, or if firmwares are needed, in which case Dynamic using mdev is usually a good solution.
The init program is the first userspace program started by the kernel (it carries the PID number 1), and is responsible for starting the userspace services and programs (for example: web server, graphical applications, other network servers, etc.).
Buildroot allows to use three different types of init systems, which
can be chosen from System configuration
, Init system
:
init
program, which is sufficient
for most embedded systems. Enabling the BR2_INIT_BUSYBOX
will
ensure Busybox will build and install its init
program. This is
the default solution in Buildroot. The Busybox init
program will
read the /etc/inittab
file at boot to know what to do. The syntax
of this file can be found in
http://git.busybox.net/busybox/tree/examples/inittab (note that
Busybox inittab
syntax is special: do not use a random inittab
documentation from the Internet to learn about Busybox
inittab
). The default inittab
in Buildroot is stored in
system/skeleton/etc/inittab
. Apart from mounting a few important
filesystems, the main job the default inittab does is to start the
/etc/init.d/rcS
shell script, and start a getty
program (which
provides a login prompt).
package/sysvinit
. This was the solution used in most desktop
Linux distributions, until they switched to more recent
alternatives such as Upstart or Systemd. sysvinit
also works with
an inittab
file (which has a slightly different syntax than the
one from Busybox). The default inittab
installed with this init
solution is located in package/sysvinit/inittab
.
systemd
is the new generation
init system for Linux. It does far more than traditional init
programs: aggressive parallelization capabilities, uses socket and
D-Bus activation for starting services, offers on-demand starting
of daemons, keeps track of processes using Linux control groups,
supports snapshotting and restoring of the system state,
etc. systemd
will be useful on relatively complex embedded
systems, for example the ones requiring D-Bus and services
communicating between each other. It is worth noting that systemd
brings a fairly big number of large dependencies: dbus
, glib
and more. For more details about systemd
, see
http://www.freedesktop.org/wiki/Software/systemd.
The solution recommended by Buildroot developers is to use the Busybox init as it is sufficient for most embedded systems. systemd can be used for more complex situations.
This is a collection of tips that help you make the most of Buildroot.
Configuration searches: The make *config
commands offer a search tool. Read the help message in
the different frontend menus to know how to use it:
/
;
Ctrl
+ f
.
The result of the search shows the help message of the matching items.
Display all commands executed by make:
$ make V=1 <target>
Display all available targets:
$ make help
Not all targets are always available,. some settings in the .config
file may hide some targets:
linux-menuconfig
and linux-savedefconfig
only work when
linux
is enabled;
uclibc-menuconfig
is only available when the
Buildroot internal toolchain backend is used;
ctng-menuconfig
is only available when the
crosstool-NG backend is used;
barebox-menuconfig
and barebox-savedefconfig
only work when the
barebox
bootloader is enabled.
Cleaning: Explicit cleaning is required when any of the architecture or toolchain configuration options are changed.
To delete all build products (including build directories, host, staging and target trees, the images and the toolchain):
$ make clean
To delete all build products as well as the configuration:
$ make distclean
Note that if ccache
is enabled, running make clean
or distclean
does
not empty the compiler cache used by Buildroot. To delete it, refer
to Section 5.2.2, “Using ccache
in Buildroot”.
Besides changing one or another configuration through make *config
,
there are a few ways to customize the resulting target filesystem.
output/target/
. You can
simply make your changes here and run make afterwards - this will
rebuild the target filesystem image. This method allows you to do
anything to the target filesystem, but if you decide to completely
rebuild your toolchain and tools, these changes will be lost. This
solution is therefore only useful for quick tests only: changes do
not survive the make clean
command. Once you have validated your
changes, you should make sure that they will persist after a make
clean
by using one of the following methods.
BR2_ROOTFS_OVERLAY
to the top of the tree. .git
, .svn
, .hg
directories, .empty
files and files ending with ~
are excluded.
Among these first 3 methods, this one should be preferred.
In the Buildroot configuration, you can specify the paths to one or
more post-build scripts. These scripts are called in the given order,
after Buildroot builds all the selected software, but before the
rootfs images are assembled. The BR2_ROOTFS_POST_BUILD_SCRIPT
allows
you to specify the location of your post-build scripts. This option can be
found in the System configuration
menu. The destination root
filesystem folder is given as the first argument to these scripts,
and these scripts can then be used to remove or modify any file in your
target filesystem. You should, however, use this feature with care.
Whenever you find that a certain package generates wrong or unneeded
files, you should fix that package rather than work around it with some
post-build cleanup scripts.
You may also use these variables in your post-build script:
BUILDROOT_CONFIG
: the path to the Buildroot .config file
HOST_DIR
, STAGING_DIR
, TARGET_DIR
: see
the section called “generic-package
Reference”
BINARIES_DIR
: the place where all binary files (aka images) are
stored
BASE_DIR
: the base output directory
system/skeleton
and then customize it to
suit your needs. The BR2_ROOTFS_SKELETON_CUSTOM
and
BR2_ROOTFS_SKELETON_CUSTOM_PATH
will allow you to specify the
location of your custom skeleton. These options can be found in the
System configuration
menu. At build time, the contents of the
skeleton are copied to output/target before any package
installation. Note that this method is not recommended, as it
duplicates the entire skeleton, which prevents from taking advantage
of the fixes or improvements brought to the default Buildroot
skeleton. The recommended method is to use the post-build scripts
mechanism described in the previous item.
Note also that you can use the post-image scripts
if you want to perform some specific actions after all
filesystem images have been created (for example to automatically
extract your root filesystem tarball in a location exported by your
NFS server, or to create a special firmware image that bundles your
root filesystem and kernel image, or any other custom action), you can
specify a space-separated list of scripts in the
BR2_ROOTFS_POST_IMAGE_SCRIPT
configuration option. This option can be
found in the System configuration
menu as well.
Each of those scripts will be called with the path to the images
output directory as first and unique argument, and will be executed
with the main Buildroot source directory as the current
directory. Those scripts will be executed as the user that executes
Buildroot, which should normally not be the root user. Therefore, any
action requiring root permissions in one of these post-image scripts
will require special handling (usage of fakeroot or sudo), which is
left to the script developer.
Just like for the post-build scripts mentioned above, you also have
access to the following environment variables from your post-image
scripts: BUILDROOT_CONFIG
, HOST_DIR
, STAGING_DIR
, TARGET_DIR
,
BINARIES_DIR
and BASE_DIR
.
Busybox is very configurable, and you may want to customize it. You can follow these simple steps to do so. This method isn’t optimal, but it’s simple, and it works:
make busybox-menuconfig
.
The nice configuration tool appears, and you can
customize everything.
Otherwise, you can simply change the
package/busybox/busybox-<version>.config
file, if you know the
options you want to change, without using the configuration tool.
If you want to use an existing config file for busybox, then see Section 3.5.5, “Environment variables”.
Just like BusyBox Section 3.3.2, “Customizing the Busybox configuration”, uClibc offers a lot of configuration options. They allow you to select various functionalities depending on your needs and limitations.
The easiest way to modify the configuration of uClibc is to follow these steps:
make uclibc-menuconfig
. The nice configuration assistant,
similar to the one used in the Linux kernel or Buildroot,
appears. Make your configuration changes as appropriate.
$(O)/toolchain/uClibc-VERSION/.config
file to a different
place (e.g. board/MANUFACTURER/BOARDNAME/uClibc.config
) and adjust
the uClibc configuration file option BR2_UCLIBC_CONFIG
to refer to this
configuration instead of the default one.
Otherwise, you can simply change toolchain/uClibc/uClibc-VERSION.config
,
without running the configuration assistant.
If you want to use an existing config file for uClibc, then see Section 3.5.5, “Environment variables”.
The Linux kernel configuration can be customized just like
BusyBox
Section 3.3.2, “Customizing the Busybox configuration” and uClibc
Section 3.3.3, “Customizing the uClibc configuration” using
make linux-menuconfig
. Make sure you have enabled the kernel build
in make menuconfig
first. Once done, run make
to (re)build
everything.
If you want to use an existing config file for Linux, then see Section 3.5.5, “Environment variables”.
There are three distinct types of toolchain backend supported in Buildroot,
available under the menu Toolchain
, invoking make menuconfig
.
There is no way of tuning an external toolchain since Buildroot does not generate it.
It also requires to set the Buildroot settings according to the toolchain ones (see the section called “External toolchain backend”).
The internal Buildroot toolchain backend only allows to generate uClibc-based toolchains.
However, it allows to tune major settings, such as:
These settings are available after selecting the Buildroot toolchain
type in
the menu Toolchain
.
The crosstool-NG toolchain backend enables a rather
limited set of settings under the Buildroot Toolchain
menu:
Then, the toolchain can be fine-tuned by invoking make ctng-menuconfig
.
When you have a buildroot configuration that you are satisfied with and you want to share it with others, put it under revision control or move on to a different buildroot project, you need to store the configuration so it can be rebuilt later. The configuration that needs to be stored consists of the buildroot configuration, the configuration files for packages that you use (kernel, busybox, uClibc, …), and your rootfs modifications.
For storing the buildroot configuration itself, buildroot offers the
following command: make savedefconfig
.
This strips the buildroot configuration down by removing configuration
options that are at their default value. The result is stored in a file
called defconfig
. If you want to save it in another place, change
the BR2_DEFCONFIG
option, or call make with make savedefconfig
BR2_DEFCONFIG=<path-to-defconfig>
. The usual place is
configs/<boardname>_defconfig
. The configuration can then be rebuilt by
running make <boardname>_defconfig
.
Alternatively, you can copy the file to any other place and rebuild with
make defconfig BR2_DEFCONFIG=<path-to-defconfig-file>
.
The configuration files for busybox, the linux kernel, barebox, uClibc and
crosstool-NG should be stored as well if changed. For each of these, a
buildroot configuration option exists to point to an input configuration
file, e.g. BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE
. To save their
configuration, set those configuration options to a path outside
your output directory, e.g. board/<manufacturer>/<boardname>/linux.config
.
Then, copy the configuration files to that path.
Make sure that you create a configuration file before changing
the BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE
etc. options. Otherwise,
buildroot will try to access this config file, which doesn’t exist
yet, and will fail. You can create the configuration file by running
make linux-menuconfig
etc.
Buildroot provides a few helper targets to make the saving of configuration files easier.
make linux-update-defconfig
saves the linux configuration to the
path specified by BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE
. It
simplifies the config file by removing default values. However,
this only works with kernels starting from 2.6.33. For earlier
kernels, use make linux-update-config
.
make busybox-update-config
saves the busybox configuration to the
path specified by BR2_PACKAGE_BUSYBOX_CONFIG
.
make uclibc-update-config
saves the uClibc configuration to the
path specified by BR2_UCLIBC_CONFIG
.
make barebox-update-defconfig
saves the barebox configuration to the
path specified by BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE
.
BR2_TOOLCHAIN_CTNG_CONFIG
,
resp. BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_CONFIG_FILE
.
Creating your own board support in Buildroot allows users of a particular hardware platform to easily build a system that is known to work.
To do so, you need to create a normal Buildroot configuration that builds a basic system for the hardware: toolchain, kernel, bootloader, filesystem and a simple Busybox-only userspace. No specific package should be selected: the configuration should be as minimal as possible, and should only build a working basic Busybox system for the target platform. You can of course use more complicated configurations for your internal projects, but the Buildroot project will only integrate basic board configurations. This is because package selections are highly application-specific.
Once you have a known working configuration, run make
savedefconfig
. This will generate a minimal defconfig
file at the
root of the Buildroot source tree. Move this file into the configs/
directory, and rename it <boardname>_defconfig
.
It is recommended to use as much as possible upstream versions of the Linux kernel and bootloaders, and to use as much as possible default kernel and bootloader configurations. If they are incorrect for your board, or no default exists, we encourage you to send fixes to the corresponding upstream projects.
However, in the mean time, you may want to store kernel or bootloader
configuration or patches specific to your target platform. To do so,
create a directory board/<manufacturer>
and a subdirectory
board/<manufacturer>/<boardname>
. You can then store your patches
and configurations in these directories, and reference them from the main
Buildroot configuration.
To store the configuration for a specific product, device or
application, it is advisable to use the same conventions as for the
board support: put the buildroot defconfig in the configs
directory,
and any other files in a subdirectory of the boards
directory. This
section gives step-by-step instructions about how to do that. Of course,
you can skip the steps that are not relevant for your use case.
make menuconfig
to configure toolchain, packages and kernel.
make linux-menuconfig
to update the kernel config, similar for
other configuration.
mkdir -p board/<manufacturer>/<boardname>
Set the following options to board/<manufacturer>/<boardname>/<package>.config
(as far as they are relevant):
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE
BR2_PACKAGE_BUSYBOX_CONFIG
BR2_TOOLCHAIN_CTNG_CONFIG
BR2_UCLIBC_CONFIG
BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_CONFIG_FILE
BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE
Write the configuration files:
make linux-update-defconfig
make busybox-update-config
cp <output>/build/build-toolchain/.config board/<manufacturer>/<boardname>/ctng.config
make uclibc-update-config
cp <output>/build/at91bootstrap3-*/.config board/<manufacturer>/<boardname>/at91bootstrap3.config
make barebox-update-defconfig
board/<manufacturer>/<boardname>/fs-overlay/
and fill it
with additional files you need on your rootfs, e.g.
board/<manufacturer>/<boardname>/fs-overlay/etc/inittab
.
Set BR2_ROOTFS_OVERLAY
to board/<manufacturer>/<boardname>/fs-overlay
.
board/<manufacturer>/<boardname>/post-build.sh
. Set
BR2_ROOTFS_POST_BUILD_SCRIPT
to
board/<manufacturer>/<boardname>/post-build.sh
board/<manufacturer>/<boardname>/device_table.txt
and add that path to BR2_ROOTFS_DEVICE_TABLE
.
make savedefconfig
to save the buildroot configuration.
cp defconfig configs/<boardname>_defconfig
BR2_LINUX_KERNEL_PATCH
to
board/<manufacturer>/<boardname>/patches/linux/
and add your
patches in that directory. Each patch should be called
linux-<num>-<description>.patch
. Similar for U-Boot, barebox,
at91bootstrap and at91bootstrap3.
packages/
directory, following the
instructions in Section 6.2, “Adding new packages to Buildroot”.
It is sometimes useful to apply extra patches to packages - over and above those provided in Buildroot. This might be used to support custom features in a project, for example, or when working on a new architecture.
The BR2_GLOBAL_PATCH_DIR
configuration file option can be
used to specify a directory containing global package patches.
For a specific version <packageversion> of a specific package <packagename>, patches are applied as follows.
First, the default Buildroot patch set for the package is applied.
If the directory $(BR2_GLOBAL_PATCH_DIR)/<packagename>/<packageversion>
exists, then all *.patch
files in the directory will be applied.
Otherwise, if the directory $(BR2_GLOBAL_PATCH_DIR)/<packagename>
exists, then all *.patch
files in the directory will be applied.
A full rebuild is achieved by running:
$ make clean all
In some cases, a full rebuild is mandatory:
each time the toolchain properties are changed, this includes:
make ctng-menuconfig
(if the crosstool-NG backend
is used);
make uclibc-menuconfig
.
In some cases, a full rebuild is recommended:
In other cases, it is up to you to decide if you should run a full rebuild, but you should know what is impacted and understand what you are doing anyway.
One of the most common questions asked by Buildroot users is how to rebuild a given package or how to remove a package without rebuilding everything from scratch.
Removing a package is unsupported by Buildroot without
rebuilding from scratch. This is because Buildroot doesn’t keep track
of which package installs what files in the output/staging
and
output/target
directories, or which package would be compiled differently
depending on the availability of another package.
The easiest way to rebuild a single package from scratch is to remove
its build directory in output/build
. Buildroot will then re-extract,
re-configure, re-compile and re-install this package from scratch. You
can ask buildroot to do this with the make <package>-dirclean
command.
For convenience, the special make targets <package>-reconfigure and <package>-rebuild repeat the configure resp. build steps.
However, if you don’t want to rebuild the package completely from scratch, a better understanding of the Buildroot internals is needed. Internally, to keep track of which steps have been done and which steps remain to be done, Buildroot maintains stamp files (empty files that just tell whether this or that action has been done):
output/build/<package>-<version>/.stamp_configured
. If removed,
Buildroot will trigger the recompilation of the package from the
configuration step (execution of ./configure
).
output/build/<package>-<version>/.stamp_built
. If removed,
Buildroot will trigger the recompilation of the package from the
compilation step (execution of make
).
Note: toolchain packages use custom makefiles. Their stamp files are named differently.
Further details about package special make targets are explained in Section 5.2.4, “Package-specific make targets”.
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.
As default, everything built by Buildroot is stored in the directory
output
in the Buildroot tree.
Buildroot also supports building out of tree with a syntax similar to
the Linux kernel. To use it, add O=<directory>
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 <target>
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/.config>
, path to
the uClibc configuration file, used to compile uClibc, if an
internal toolchain is being built.
Note that the uClibc configuration file can also be set from the
configuration interface, so through the Buildroot .config
file; this
is the recommended way of setting it.
BUSYBOX_CONFIG_FILE=<path/to/.config>
, path to
the Busybox configuration file.
Note that the Busybox configuration file can also be set from the
configuration interface, so through the Buildroot .config
file; this
is the recommended way of setting it.
BUILDROOT_DL_DIR
to override the directory in which
Buildroot stores/retrieves downloaded files
Note that the Buildroot download directory can also be set from the
configuration interface, so through the Buildroot .config
file; this
is the recommended way of setting it.
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
While a part of the embedded Linux developers like classical text editors like Vim or Emacs, and command-line based interfaces, a number of other embedded Linux developers like richer graphical interfaces to do their development work. Eclipse being one of the most popular Integrated Development Environment, Buildroot integrates with Eclipse in order to ease the development work of Eclipse users.
Our integration with Eclipse simplifies the compilation, remote execution and remote debugging of applications and libraries that are built on top of a Buildroot system. It does not integrate the Buildroot configuration and build processes themselves with Eclipse. Therefore, the typical usage model of our Eclipse integration would be:
make menuconfig
, make
xconfig
or any other configuration interface provided with
Buildroot.
make
.
The Buildroot Eclipse integration installation process and usage is described in detail at https://github.com/mbats/eclipse-buildroot-bundle/wiki.
If Buildroot does not yet fit all your requirements, you may be interested in hacking it to add:
[3] This terminology differs from what is used by GNU configure, where the host is the machine on which the application will run (which is usually the same as target)
If the boot process seems to hang after the following messages (messages not necessarily exactly similar, depending on the list of packages selected):
Freeing init memory: 3972K Initializing random number generator... done. Starting network... Starting dropbear sshd: generating rsa key... generating dsa key... OK
then it means that your system is running, but didn’t start a shell on
the serial console. In order to have the system start a shell on your
serial console, you have to go into the Buildroot configuration, System
configuration
, and modify Port to run a getty (login prompt) on
and
Baudrate to use
as appropriate. This will automatically tune the
/etc/inittab
file of the generated system so that a shell starts on
the correct serial port.
If the build of module-init-tools
for the host fails with:
/usr/bin/ld: cannot find -lc
then probably you are running a Fedora (or similar) distribution, and
you should install the glibc-static
package. This is because the
module-init-tools
build process wants to link statically against the
C library.
It has been decided that support for the native compiler on the target would be stopped from the Buildroot-2012.11 release because:
If you need a compiler on your target anyway, then Buildroot is not suitable for your purpose. In such case, you need a real distribution and you should opt for something like:
Since there is no compiler available on the target (see Section 4.3, “Why is there no compiler on the target?”), it does not make sense to waste space with headers or static libraries.
Therefore, those files are always removed from the target since the Buildroot-2012.11 release.
Because Buildroot mostly targets small or very small target hardware with limited resource onboard (CPU, ram, mass-storage), it does not make sense to waste space with the documentation data.
If you need documentation data on your target anyway, then Buildroot is not suitable for your purpose, and you should look for a real distribution (see: Section 4.3, “Why is there no compiler on the target?”).
If a package exists in the Buildroot tree and does not appear in the config menu, this most likely means that some of the package’s dependencies are not met.
To know more about the dependencies of a package, search for the package symbol in the config menu (see Section 3.2, “make tips”).
Then, you may have to recursively enable several options (which correspond to the unmet dependencies) to finally be able to select the package.
If the package is not visible due to some unmet toolchain options, then you should certainly run a full rebuild (see Section 3.2, “make tips” for more explanations).
There are plenty of reasons to not use the target directory a chroot one, among these:
For these reasons, commands run through chroot, using the target directory as the new root, will most likely fail.
If you want to run the target filesystem inside a chroot, or as an NFS
root, then use the tarball image generated in images/
and extract it
as root.
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.
toolchain/
directory contains the Makefiles
and associated files for all software related to the
cross-compilation toolchain: binutils
, gcc
, gdb
,
kernel-headers
and uClibc
.
arch/
directory contains the definitions for all the processor
architectures that are supported by Buildroot.
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.
linux/
directory contains the Makefiles and associated files for
the Linux kernel.
boot/
directory contains the Makefiles and associated files for
the bootloaders supported by Buildroot.
system/
directory contains support for system integration, e.g.
the target filesystem skeleton and the selection of an init system.
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:
something.mk
is the Makefile that downloads, configures,
compiles and installs the package something
.
Config.in
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):
staging
, target
, build
,
stamps
, etc. in the output directory (output/
by default,
another value can be specified using O=
)
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.
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.
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.
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
.
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.
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 |
| Re-run the configure commands, then rebuild - this only
makes sense when using the |
Overall, these coding style rules are here to help you to add new files in Buildroot or refactor existing ones.
If you slightly modify some existing file, the important thing is to keep the consistency of the whole file, so you can:
Config.in
files contain entries for almost anything configurable in
Buildroot.
An entry has the following pattern:
config BR2_PACKAGE_LIBFOO bool "libfoo" depends on BR2_PACKAGE_LIBBAZ select BR2_PACKAGE_LIBBAR help This is a comment that explains what libfoo is. http://foosoftware.org/libfoo/
bool
, depends on
, select
and help
lines are indented
with one tab.
The Config.in
files are the input for the configuration tool
used in Buildroot, which is the regular Kconfig. For further
details about the Kconfig language, refer to
http://kernel.org/doc/Documentation/kbuild/kconfig-language.txt.
Assignment: use =
preceded and followed by one space:
LIBFOO_VERSION = 1.0 LIBFOO_CONF_OPT += --without-python-support
It is also possible to align the =
signs:
LIBFOO_VERSION = 1.0 LIBFOO_SOURCE = foo-$(LIBFOO_VERSION).tar.gz LIBFOO_CONF_OPT += --without-python-support
Indentation: use tab only:
define LIBFOO_REMOVE_DOC $(RM) -fr $(TARGET_DIR)/usr/share/libfoo/doc \ $(TARGET_DIR)/usr/share/man/man3/libfoo* endef
Note that commands inside a define
block should always start with a tab,
so make recognizes them as commands.
Optional dependency:
Prefer multi-line syntax.
YES:
ifeq ($(BR2_PACKAGE_PYTHON),y) LIBFOO_CONF_OPT += --with-python-support LIBFOO_DEPENDENCIES += python else LIBFOO_CONF_OPT += --without-python-support endif
NO:
LIBFOO_CONF_OPT += --with$(if $(BR2_PACKAGE_PYTHON),,out)-python-support LIBFOO_DEPENDENCIES += $(if $(BR2_PACKAGE_PYTHON),python,)
Optional hooks: keep hook definition and assignment together in one if block.
YES:
ifneq ($(BR2_LIBFOO_INSTALL_DATA),y) define LIBFOO_REMOVE_DATA $(RM) -fr $(TARGET_DIR)/usr/share/libfoo/data endef LIBFOO_POST_INSTALL_TARGET_HOOKS += LIBFOO_REMOVE_DATA endif
NO:
define LIBFOO_REMOVE_DATA $(RM) -fr $(TARGET_DIR)/usr/share/libfoo/data endef ifneq ($(BR2_LIBFOO_INSTALL_DATA),y) LIBFOO_POST_INSTALL_TARGET_HOOKS += LIBFOO_REMOVE_DATA endif
The documentation uses the asciidoc format.
For further details about the asciidoc syntax, refer to http://www.methods.co.nz/asciidoc/userguide.html.
This section covers how new packages (userspace libraries or applications) can be integrated into Buildroot. It also shows how existing packages are integrated, which is needed for fixing issues or tuning their configuration.
First of all, create a directory under the package
directory for
your software, for example libfoo
.
Some packages have been grouped by topic in a sub-directory:
multimedia
, x11r7
, efl
and matchbox
. If your package fits in
one of these categories, then create your package directory in these.
New subdirectories are discouraged, however.
Then, create a file named Config.in
. This file will contain the
option descriptions related to our libfoo
software that will be used
and displayed in the configuration tool. It should basically contain:
config BR2_PACKAGE_LIBFOO bool "libfoo" help This is a comment that explains what libfoo is. http://foosoftware.org/libfoo/
The bool
line, help
line and other meta-informations about the
configuration option must be indented with one tab. The help text
itself should be indented with one tab and two spaces, and it must
mention the upstream URL of the project.
You can add other sub-options into a if
BR2_PACKAGE_LIBFOO…endif
statement to configure particular things
in your software. You can look at examples in other packages. The
syntax of the Config.in
file is the same as the one for the kernel
Kconfig file. The documentation for this syntax is available at
http://kernel.org/doc/Documentation/kbuild/kconfig-language.txt
Finally you have to add your new libfoo/Config.in
to
package/Config.in
(or in a category subdirectory if you decided to
put your package in one of the existing categories). The files
included there are sorted alphabetically per category and are NOT
supposed to contain anything but the bare name of the package.
source "package/libfoo/Config.in"
The Config.in
file of your package must also ensure that
dependencies are enabled. Typically, Buildroot uses the following
rules:
select
type of dependency for dependencies on
libraries. These dependencies are generally not obvious and it
therefore make sense to have the kconfig system ensure that the
dependencies are selected. For example, the libgtk2 package uses
select BR2_PACKAGE_LIBGLIB2
to make sure this library is also
enabled.
The select
keyword express the dependency with a backward
semantic.
depends on
type of dependency when the user really needs to
be aware of the dependency. Typically, Buildroot uses this type of
dependency for dependencies on toolchain options (target
architecture, MMU support, C library, C++ support, large file
support, thread support, RPC support, IPV6 support, WCHAR support),
or for dependencies on "big" things, such as the X.org system. For
dependencies on toolchain options, there should be a comment
that
is displayed when the option is not
enabled, so that the user knows why the package is not available.
The depends on
keyword express the dependency with a forward
semantic.
Note. The current problem with the kconfig language is that these two dependency semantics are not internally linked. Therefore, it may be possible to select a package, whom one of its dependencies/requirement is not met.
An example illustrates both the usage of select
and depends on
.
config BR2_PACKAGE_ACL bool "acl" select BR2_PACKAGE_ATTR depends on BR2_LARGEFILE help POSIX Access Control Lists, which are used to define more fine-grained discretionary access rights for files and directories. This package also provides libacl. http://savannah.nongnu.org/projects/acl comment "acl requires a toolchain with LARGEFILE support" depends on !BR2_LARGEFILE
Note that these two dependency types are only transitive with the dependencies of the same kind.
This means, in the following example:
config BR2_PACKAGE_A bool "Package A" config BR2_PACKAGE_B bool "Package B" depends on BR2_PACKAGE_A config BR2_PACKAGE_C bool "Package C" depends on BR2_PACKAGE_B config BR2_PACKAGE_D bool "Package D" select BR2_PACKAGE_B config BR2_PACKAGE_E bool "Package E" select BR2_PACKAGE_D
Package C
will be visible if Package B
has been
selected, which in turn is only visible if Package A
has been
selected.
Package E
will select Package D
, which will select
Package B
, it will not check for the dependencies of Package B
,
so it will not select Package A
.
Package B
is selected but Package A
is not, this violates
the dependency of Package B
on Package A
. Therefore, in such a
situation, the transitive dependency has to be added explicitly:
config BR2_PACKAGE_D bool "Package D" select BR2_PACKAGE_B depends on BR2_PACKAGE_A config BR2_PACKAGE_E bool "Package E" select BR2_PACKAGE_D depends on BR2_PACKAGE_A
Overall, for package library dependencies, select
should be
preferred.
Note that such dependencies will ensure that the dependency option
is also enabled, but not necessarily built before your package. To do
so, the dependency also needs to be expressed in the .mk
file of the
package.
Further formatting details: see the
coding style
Section 6.1.1, “Config.in
file”.
Finally, here’s the hardest part. Create a file named libfoo.mk
. It
describes how the package should be downloaded, configured, built,
installed, etc.
Depending on the package type, the .mk
file must be written in a
different way, using different infrastructures:
generic-package
Tutorial” and a
reference
the section called “generic-package
Reference”.
autotools-package
tutorial”
and reference
the section called “autotools-package
reference”.
cmake-package
tutorial”
and reference
the section called “cmake-package
reference”.
Further formating details: see the writing
rules
Section 6.1.2, “The .mk
file”.
By packages with specific build systems we mean all the packages whose build system is not one of the standard ones, such as autotools or CMake. This typically includes packages whose build system is based on hand-written Makefiles or shell scripts.
01: ############################################################# 02: # 03: # libfoo 04: # 05: ############################################################# 06: 07: LIBFOO_VERSION = 1.0 08: LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz 09: LIBFOO_SITE = http://www.foosoftware.org/download 10: LIBFOO_LICENSE = GPLv3+ 11: LIBFOO_LICENSE_FILES = COPYING 12: LIBFOO_INSTALL_STAGING = YES 13: LIBFOO_CONFIG_SCRIPTS = libfoo-config 14: LIBFOO_DEPENDENCIES = host-libaaa libbbb 15: 16: define LIBFOO_BUILD_CMDS 17: $(MAKE) CC="$(TARGET_CC)" LD="$(TARGET_LD)" -C $(@D) all 18: endef 19: 20: define LIBFOO_INSTALL_STAGING_CMDS 21: $(INSTALL) -D -m 0755 $(@D)/libfoo.a $(STAGING_DIR)/usr/lib/libfoo.a 22: $(INSTALL) -D -m 0644 $(@D)/foo.h $(STAGING_DIR)/usr/include/foo.h 23: $(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(STAGING_DIR)/usr/lib 24: endef 25: 26: define LIBFOO_INSTALL_TARGET_CMDS 27: $(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(TARGET_DIR)/usr/lib 28: $(INSTALL) -d -m 0755 $(TARGET_DIR)/etc/foo.d 29: endef 30: 31: define LIBFOO_DEVICES 32: /dev/foo c 666 0 0 42 0 - - - 33: endef 34: 35: define LIBFOO_PERMISSIONS 36: /bin/foo f 4755 0 0 - - - - - 37: endef 38: 39: define LIBFOO_USERS 40: foo -1 libfoo -1 * - - - LibFoo daemon 41: endef 42: 43: $(eval $(generic-package))
The Makefile begins on line 7 to 11 with metadata information: the
version of the package (LIBFOO_VERSION
), the name of the
tarball containing the package (LIBFOO_SOURCE
) the
Internet location at which the tarball can be downloaded from
(LIBFOO_SITE
), the license (LIBFOO_LICENSE
) and file with the
license text (LIBFOO_LICENSE_FILES
). All variables must start with
the same prefix, LIBFOO_
in this case. This prefix is always the
uppercased version of the package name (see below to understand where
the package name is defined).
On line 12, we specify that this package wants to install something to
the staging space. This is often needed for libraries, since they must
install header files and other development files in the staging space.
This will ensure that the commands listed in the
LIBFOO_INSTALL_STAGING_CMDS
variable will be executed.
On line 13, we specify that there is some fixing to be done to some
of the libfoo-config files that were installed during
LIBFOO_INSTALL_STAGING_CMDS
phase.
These *-config files are executable shell script files that are
located in $(STAGING_DIR)/usr/bin directory and are executed
by other 3rd party packages to find out the location and the linking
flags of this particular package.
The problem is that all these *-config files by default give wrong, host system linking flags that are unsuitable for cross-compiling.
For example: -I/usr/include instead of -I$(STAGING_DIR)/usr/include or: -L/usr/lib instead of -L$(STAGING_DIR)/usr/lib
So some sed magic is done to these scripts to make them give correct
flags.
The argument to be given to LIBFOO_CONFIG_SCRIPTS
is the file name(s)
of the shell script(s) needing fixing. All these names are relative to
$(STAGING_DIR)/usr/bin and if needed multiple names can be given.
In addition, the scripts listed in LIBFOO_CONFIG_SCRIPTS
are removed
from $(TARGET_DIR)/usr/bin
, since they are not needed on the target.
Example 1:
Package divine installs shell script $(STAGING_DIR)/usr/bin/divine-config.
So it’s fixup would be:
DIVINE_CONFIG_SCRIPTS = divine-config
Example 2:
Package imagemagick installs the following scripts: $(STAGING_DIR)/usr/bin/{Magick,Magick++,MagickCore,MagickWand,Wand}-config
So it’s fixup would be:
IMAGEMAGICK_CONFIG_SCRIPTS = \ Magick-config Magick++-config \ MagickCore-config MagickWand-config Wand-config
On line 14, we specify the list of dependencies this package relies
on. These dependencies are listed in terms of lower-case package names,
which can be packages for the target (without the host-
prefix) or packages for the host (with the host-
) prefix).
Buildroot will ensure that all these packages are built and installed
before the current package starts its configuration.
The rest of the Makefile, lines 16..29, defines what should be done
at the different steps of the package configuration, compilation and
installation.
LIBFOO_BUILD_CMDS
tells what steps should be performed to
build the package. LIBFOO_INSTALL_STAGING_CMDS
tells what
steps should be performed to install the package in the staging space.
LIBFOO_INSTALL_TARGET_CMDS
tells what steps should be
performed to install the package in the target space.
All these steps rely on the $(@D)
variable, which
contains the directory where the source code of the package has been
extracted.
On line 31..33, we define a device-node file used by this package
(LIBFOO_DEVICES
).
On line 35..37, we define the permissions to set to specific files
installed by this package (LIBFOO_PERMISSIONS
).
On lines 39..41, we define a user that is used by this package (eg.
to run a daemon as non-root) (LIBFOO_USERS
).
Finally, on line 43, we call the generic-package
function, which
generates, according to the variables defined previously, all the
Makefile code necessary to make your package working.
There are two variants of the generic target. The generic-package
macro is
used for packages to be cross-compiled for the target. The
host-generic-package
macro is used for host packages, natively compiled
for the host. It is possible to call both of them in a single .mk
file: once to create the rules to generate a target
package and once to create the rules to generate a host package:
$(eval $(generic-package)) $(eval $(host-generic-package))
This might be useful if the compilation of the target package requires
some tools to be installed on the host. If the package name is
libfoo
, then the name of the package for the target is also
libfoo
, while the name of the package for the host is
host-libfoo
. These names should be used in the DEPENDENCIES
variables of other packages, if they depend on libfoo
or
host-libfoo
.
The call to the generic-package
and/or host-generic-package
macro must be
at the end of the .mk
file, after all variable definitions.
For the target package, the generic-package
uses the variables defined by
the .mk file and prefixed by the uppercased package name:
LIBFOO_*
. host-generic-package
uses the HOST_LIBFOO_*
variables. For
some variables, if the HOST_LIBFOO_
prefixed variable doesn’t
exist, the package infrastructure uses the corresponding variable
prefixed by LIBFOO_
. This is done for variables that are likely to
have the same value for both the target and host packages. See below
for details.
The list of variables that can be set in a .mk
file to give metadata
information is (assuming the package name is libfoo
) :
LIBFOO_VERSION
, mandatory, must contain the version of the
package. Note that if HOST_LIBFOO_VERSION
doesn’t exist, it is
assumed to be the same as LIBFOO_VERSION
. It can also be a
revision number, branch or tag for packages that are fetched
directly from their revision control system.
Examples:
LIBFOO_VERSION = 0.1.2
LIBFOO_VERSION = cb9d6aa9429e838f0e54faa3d455bcbab5eef057
LIBFOO_VERSION = stable
LIBFOO_SOURCE
may contain the name of the tarball of
the package. If HOST_LIBFOO_SOURCE
is not specified, it
defaults to LIBFOO_SOURCE
. If none are specified, then
the value is assumed to be
packagename-$(LIBFOO_VERSION).tar.gz
.
Example: LIBFOO_SOURCE = foobar-$(LIBFOO_VERSION).tar.bz2
LIBFOO_PATCH
may contain a space-separated list of patch file
names, that will be downloaded from the same location as the tarball
indicated in LIBFOO_SOURCE
, and then applied to the package source
code. If HOST_LIBFOO_PATCH
is not specified, it defaults to
LIBFOO_PATCH
. Note that patches that are included in Buildroot
itself use a different mechanism: all files of the form
<packagename>-*.patch
present in the package directory inside
Buildroot will be applied to the package after extraction (see
patching a package
Section 6.3, “Patching a package”). Finally, patches listed in
the LIBFOO_PATCH
variable are applied before the patches stored
in the Buildroot package directory.
LIBFOO_SITE
provides the location of the package, which can be a
URL or a local filesystem path. HTTP, FTP and SCP are supported URL
types for retrieving package tarballs. Git, Subversion, Mercurial,
and Bazaar are supported URL types for retrieving packages directly
from source code management systems. A filesystem path may be used
to specify either a tarball or a directory containing the package
source code. See LIBFOO_SITE_METHOD
below for more details on how
retrieval works.
Note that SCP URLs should be of the form
scp://[user@]host:filepath
, and that filepath is relative to the
user’s home directory, so you may want to prepend the path with a
slash for absolute paths:
scp://[user@]host:/absolutepath
.
If HOST_LIBFOO_SITE
is not specified, it defaults to
LIBFOO_SITE
.
Examples:
LIBFOO_SITE=http://www.libfoosoftware.org/libfoo
LIBFOO_SITE=http://svn.xiph.org/trunk/Tremor/
LIBFOO_SITE=git://github.com/kergoth/tslib.git
LIBFOO_SITE=/opt/software/libfoo.tar.gz
LIBFOO_SITE=$(TOPDIR)/../src/libfoo/
LIBFOO_SITE_METHOD
determines the method used to fetch or copy the
package source code. In many cases, Buildroot guesses the method
from the contents of LIBFOO_SITE
and setting LIBFOO_SITE_METHOD
is unnecessary. When HOST_LIBFOO_SITE_METHOD
is not specified, it
defaults to the value of LIBFOO_SITE_METHOD
.
The possible values of LIBFOO_SITE_METHOD
are:
wget
for normal FTP/HTTP downloads of tarballs. Used by
default when LIBFOO_SITE
begins with http://
, https://
or
ftp://
.
scp
for downloads of tarballs over SSH with scp. Used by
default when LIBFOO_SITE
begins with scp://
.
svn
for retrieving source code from a Subversion repository.
Used by default when LIBFOO_SITE
begins with svn://
. When a
http://
Subversion repository URL is specified in
LIBFOO_SITE
, one must specify LIBFOO_SITE_METHOD=svn
.
Buildroot performs a checkout which is preserved as a tarball in
the download cache; subsequent builds use the tarball instead of
performing another checkout.
git
for retrieving source code from a Git repository. Used by
default when LIBFOO_SITE
begins with git://
. The downloaded
source code is cached as with the svn
method.
hg
for retrieving source code from a Mercurial repository. One
must specify LIBFOO_SITE_METHOD=hg
when LIBFOO_SITE
contains a Mercurial repository URL. The downloaded source code
is cached as with the svn
method.
bzr
for retrieving source code from a Bazaar repository. Used
by default when LIBFOO_SITE
begins with bzr://
. The
downloaded source code is cached as with the svn
method.
file
for a local tarball. One should use this when
LIBFOO_SITE
specifies a package tarball as a local filename.
Useful for software that isn’t available publicly or in version
control.
local
for a local source code directory. One should use this
when LIBFOO_SITE
specifies a local directory path containing
the package source code. Buildroot copies the contents of the
source directory into the package’s build directory.
LIBFOO_DEPENDENCIES
lists the dependencies (in terms of package
name) that are required for the current target package to
compile. These dependencies are guaranteed to be compiled and
installed before the configuration of the current package starts. In
a similar way, HOST_LIBFOO_DEPENDENCIES
lists the dependencies for
the current host package.
LIBFOO_INSTALL_STAGING
can be set to YES
or NO
(default). If
set to YES
, then the commands in the LIBFOO_INSTALL_STAGING_CMDS
variables are executed to install the package into the staging
directory.
LIBFOO_INSTALL_TARGET
can be set to YES
(default) or NO
. If
set to YES
, then the commands in the LIBFOO_INSTALL_TARGET_CMDS
variables are executed to install the package into the target
directory.
LIBFOO_CONFIG_SCRIPTS
lists the names of the files in
$(STAGING_DIR)/usr/bin that need some special fixing to make them
cross-compiling friendly. Multiple file names separated by space can
be given and all are relative to $(STAGING_DIR)/usr/bin. The files
listed in LIBFOO_CONFIG_SCRIPTS
are also removed from
$(TARGET_DIR)/usr/bin
since they are not needed on the target.
LIBFOO_DEVICES
lists the device files to be created by Buildroot
when using the static device table. The syntax to use is the
makedevs one. You can find some documentation for this syntax in the
Section 11.1, “Makedev syntax documentation”. This variable is optional.
LIBFOO_PERMISSIONS
lists the changes of permissions to be done at
the end of the build process. The syntax is once again the makedevs one.
You can find some documentation for this syntax in the Section 11.1, “Makedev syntax documentation”.
This variable is optional.
LIBFOO_USERS
lists the users to create for this package, if it installs
a program you want to run as a specific user (eg. as a daemon, or as a
cron-job). The syntax is similar in spirit to the makedevs one, and is
described in the Section 11.2, “Makeuser syntax documentation”. This variable is optional.
LIBFOO_LICENSE
defines the license (or licenses) under which the package
is released.
This name will appear in the manifest file produced by make legal-info
.
If the license appears in the following list
Section 7.2, “License abbreviations”,
use the same string to make the manifest file uniform.
Otherwise, describe the license in a precise and concise way, avoiding
ambiguous names such as BSD
which actually name a family of licenses.
This variable is optional. If it is not defined, unknown
will appear in
the license
field of the manifest file for this package.
LIBFOO_LICENSE_FILES
is a space-separated list of files in the package
tarball that contain the license(s) under which the package is released.
make legal-info
copies all of these files in the legal-info
directory.
See Chapter 7, Legal notice and licensing for more information.
This variable is optional. If it is not defined, a warning will be produced
to let you know, and not saved
will appear in the license files
field
of the manifest file for this package.
LIBFOO_REDISTRIBUTE
can be set to YES
(default) or NO
to indicate if
the package source code is allowed to be redistributed. Set it to NO
for
non-opensource packages: Buildroot will not save the source code for this
package when collecting the legal-info
.
The recommended way to define these variables is to use the following syntax:
LIBFOO_VERSION = 2.32
Now, the variables that define what should be performed at the different steps of the build process.
LIBFOO_CONFIGURE_CMDS
lists the actions to be performed to
configure the package before its compilation.
LIBFOO_BUILD_CMDS
lists the actions to be performed to
compile the package.
HOST_LIBFOO_INSTALL_CMDS
lists the actions to be performed
to install the package, when the package is a host package. The
package must install its files to the directory given by
$(HOST_DIR)
. All files, including development files such as
headers should be installed, since other packages might be compiled
on top of this package.
LIBFOO_INSTALL_TARGET_CMDS
lists the actions to be
performed to install the package to the target directory, when the
package is a target package. The package must install its files to
the directory given by $(TARGET_DIR)
. Only the files required for
execution of the package have to be
installed. Header files, static libraries and documentation will be
removed again when the target filesystem is finalized.
LIBFOO_INSTALL_STAGING_CMDS
lists the actions to be
performed to install the package to the staging directory, when the
package is a target package. The package must install its files to
the directory given by $(STAGING_DIR)
. All development files
should be installed, since they might be needed to compile other
packages.
LIBFOO_CLEAN_CMDS
, lists the actions to perform to clean up
the build directory of the package.
LIBFOO_UNINSTALL_TARGET_CMDS
lists the actions to
uninstall the package from the target directory $(TARGET_DIR)
LIBFOO_UNINSTALL_STAGING_CMDS
lists the actions to
uninstall the package from the staging directory $(STAGING_DIR)
.
LIBFOO_INSTALL_INIT_SYSV
and LIBFOO_INSTALL_INIT_SYSTEMD
list the
actions to install init scripts either for the systemV-like init systems
(busybox, sysvinit, etc.) or for the systemd units. These commands
will be run only when the relevant init system is installed (i.e. if
systemd is selected as the init system in the configuration, only
LIBFOO_INSTALL_INIT_SYSTEMD
will be run).
The preferred way to define these variables is:
define LIBFOO_CONFIGURE_CMDS action 1 action 2 action 3 endef
In the action definitions, you can use the following variables:
$(@D)
, which contains the directory in which the package source
code has been uncompressed.
$(TARGET_CC)
, $(TARGET_LD)
, etc. to get the target
cross-compilation utilities
$(TARGET_CROSS)
to get the cross-compilation toolchain prefix
$(HOST_DIR)
, $(STAGING_DIR)
and $(TARGET_DIR)
variables to install the packages properly.
The last feature of the generic infrastructure is the ability to add
hooks. These define further actions to perform after existing steps.
Most hooks aren’t really useful for generic packages, since the .mk
file already has full control over the actions performed in each step
of the package construction. The hooks are more useful for packages
using the autotools infrastructure described below. However, since
they are provided by the generic infrastructure, they are documented
here. The exception is LIBFOO_POST_PATCH_HOOKS
. Patching the
package and producing legal info are not user definable, so
LIBFOO_POST_PATCH_HOOKS
and LIBFOO_POST_LEGAL_INFO_HOOKS
are
useful for generic packages.
The following hook points are available:
LIBFOO_POST_DOWNLOAD_HOOKS
LIBFOO_POST_EXTRACT_HOOKS
LIBFOO_PRE_PATCH_HOOKS
LIBFOO_POST_PATCH_HOOKS
LIBFOO_PRE_CONFIGURE_HOOKS
LIBFOO_POST_CONFIGURE_HOOKS
LIBFOO_POST_BUILD_HOOKS
LIBFOO_POST_INSTALL_HOOKS
(for host packages only)
LIBFOO_POST_INSTALL_STAGING_HOOKS
(for target packages only)
LIBFOO_POST_INSTALL_TARGET_HOOKS
(for target packages only)
LIBFOO_POST_LEGAL_INFO_HOOKS
These variables are lists of variable names containing actions to be performed at this hook point. This allows several hooks to be registered at a given hook point. Here is an example:
define LIBFOO_POST_PATCH_FIXUP action1 action2 endef LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
First, let’s see how to write a .mk
file for an autotools-based
package, with an example :
01: ############################################################# 02: # 03: # libfoo 04: # 05: ############################################################# 06: 07: LIBFOO_VERSION = 1.0 08: LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz 09: LIBFOO_SITE = http://www.foosoftware.org/download 10: LIBFOO_INSTALL_STAGING = YES 11: LIBFOO_INSTALL_TARGET = NO 12: LIBFOO_CONF_OPT = --disable-shared 13: LIBFOO_DEPENDENCIES = libglib2 host-pkgconf 14: 15: $(eval $(autotools-package))
On line 7, we declare the version of the package.
On line 8 and 9, we declare the name of the tarball and the location of the tarball on the Web. Buildroot will automatically download the tarball from this location.
On line 10, we tell Buildroot to install the package to the staging
directory. The staging directory, located in output/staging/
is the directory where all the packages are installed, including their
development files, etc. By default, packages are not installed to the
staging directory, since usually, only libraries need to be installed in
the staging directory: their development files are needed to compile
other libraries or applications depending on them. Also by default, when
staging installation is enabled, packages are installed in this location
using the make install
command.
On line 11, we tell Buildroot to not install the package to the
target directory. This directory contains what will become the root
filesystem running on the target. For purely static libraries, it is
not necessary to install them in the target directory because they will
not be used at runtime. By default, target installation is enabled; setting
this variable to NO is almost never needed. Also by default, packages are
installed in this location using the make install
command.
On line 12, we tell Buildroot to pass a custom configure option, that
will be passed to the ./configure
script before configuring
and building the package.
On line 13, we declare our dependencies, so that they are built before the build process of our package starts.
Finally, on line line 15, we invoke the autotools-package
macro that generates all the Makefile rules that actually allows the
package to be built.
The main macro of the autotools package infrastructure is
autotools-package
. It is similar to the generic-package
macro. The ability to
have target and host packages is also available, with the
host-autotools-package
macro.
Just like the generic infrastructure, the autotools infrastructure
works by defining a number of variables before calling the
autotools-package
macro.
First, all the package metadata information variables that exist in the
generic infrastructure also exist in the autotools infrastructure:
LIBFOO_VERSION
, LIBFOO_SOURCE
,
LIBFOO_PATCH
, LIBFOO_SITE
,
LIBFOO_SUBDIR
, LIBFOO_DEPENDENCIES
,
LIBFOO_INSTALL_STAGING
, LIBFOO_INSTALL_TARGET
.
A few additional variables, specific to the autotools infrastructure, can also be defined. Many of them are only useful in very specific cases, typical packages will therefore only use a few of them.
LIBFOO_SUBDIR
may contain the name of a subdirectory
inside the package that contains the configure script. This is useful,
if for example, the main configure script is not at the root of the
tree extracted by the tarball. If HOST_LIBFOO_SUBDIR
is
not specified, it defaults to LIBFOO_SUBDIR
.
LIBFOO_CONF_ENV
, to specify additional environment
variables to pass to the configure script. By default, empty.
LIBFOO_CONF_OPT
, to specify additional configure
options to pass to the configure script. By default, empty.
LIBFOO_MAKE
, to specify an alternate make
command. This is typically useful when parallel make is enabled in
the configuration (using BR2_JLEVEL
) but that this
feature should be disabled for the given package, for one reason or
another. By default, set to $(MAKE)
. If parallel building
is not supported by the package, then it should be set to
LIBFOO_MAKE=$(MAKE1)
.
LIBFOO_MAKE_ENV
, to specify additional environment
variables to pass to make in the build step. These are passed before
the make
command. By default, empty.
LIBFOO_MAKE_OPT
, to specify additional variables to
pass to make in the build step. These are passed after the
make
command. By default, empty.
LIBFOO_AUTORECONF
, tells whether the package should
be autoreconfigured or not (i.e, if the configure script and
Makefile.in files should be re-generated by re-running autoconf,
automake, libtool, etc.). Valid values are YES
and
NO
. By default, the value is NO
LIBFOO_AUTORECONF_OPT
to specify additional options
passed to the autoreconf program if
LIBFOO_AUTORECONF=YES
. By default, empty.
LIBFOO_LIBTOOL_PATCH
tells whether the Buildroot
patch to fix libtool cross-compilation issues should be applied or
not. Valid values are YES
and NO
. By
default, the value is YES
LIBFOO_INSTALL_STAGING_OPT
contains the make options
used to install the package to the staging directory. By default, the
value is DESTDIR=$(STAGING_DIR) install
, which is
correct for most autotools packages. It is still possible to override
it.
LIBFOO_INSTALL_TARGET_OPT
contains the make options
used to install the package to the target directory. By default, the
value is DESTDIR=$(TARGET_DIR) install
. The default
value is correct for most autotools packages, but it is still possible
to override it if needed.
LIBFOO_CLEAN_OPT
contains the make options used to
clean the package. By default, the value is clean
.
LIBFOO_UNINSTALL_STAGING_OPT
, contains the make
options used to uninstall the package from the staging directory. By
default, the value is DESTDIR=$$(STAGING_DIR) uninstall
.
LIBFOO_UNINSTALL_TARGET_OPT
, contains the make
options used to uninstall the package from the target directory. By
default, the value is DESTDIR=$$(TARGET_DIR) uninstall
.
With the autotools infrastructure, all the steps required to build and install the packages are already defined, and they generally work well for most autotools-based packages. However, when required, it is still possible to customize what is done in any particular step:
.mk
file defines its
own LIBFOO_CONFIGURE_CMDS
variable, it will be used
instead of the default autotools one. However, using this method
should be restricted to very specific cases. Do not use it in the
general case.
First, let’s see how to write a .mk
file for a CMake-based package,
with an example :
01: ############################################################# 02: # 03: # libfoo 04: # 05: ############################################################# 06: 07: LIBFOO_VERSION = 1.0 08: LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz 09: LIBFOO_SITE = http://www.foosoftware.org/download 10: LIBFOO_INSTALL_STAGING = YES 11: LIBFOO_INSTALL_TARGET = NO 12: LIBFOO_CONF_OPT = -DBUILD_DEMOS=ON 13: LIBFOO_DEPENDENCIES = libglib2 host-pkgconf 14: 15: $(eval $(cmake-package))
On line 7, we declare the version of the package.
On line 8 and 9, we declare the name of the tarball and the location of the tarball on the Web. Buildroot will automatically download the tarball from this location.
On line 10, we tell Buildroot to install the package to the staging
directory. The staging directory, located in output/staging/
is the directory where all the packages are installed, including their
development files, etc. By default, packages are not installed to the
staging directory, since usually, only libraries need to be installed in
the staging directory: their development files are needed to compile
other libraries or applications depending on them. Also by default, when
staging installation is enabled, packages are installed in this location
using the make install
command.
On line 11, we tell Buildroot to not install the package to the
target directory. This directory contains what will become the root
filesystem running on the target. For purely static libraries, it is
not necessary to install them in the target directory because they will
not be used at runtime. By default, target installation is enabled; setting
this variable to NO is almost never needed. Also by default, packages are
installed in this location using the make install
command.
On line 12, we tell Buildroot to pass custom options to CMake when it is configuring the package.
On line 13, we declare our dependencies, so that they are built before the build process of our package starts.
Finally, on line line 15, we invoke the cmake-package
macro that generates all the Makefile rules that actually allows the
package to be built.
The main macro of the CMake package infrastructure is
cmake-package
. It is similar to the generic-package
macro. The ability to
have target and host packages is also available, with the
host-cmake-package
macro.
Just like the generic infrastructure, the CMake infrastructure works
by defining a number of variables before calling the cmake-package
macro.
First, all the package metadata information variables that exist in
the generic infrastructure also exist in the CMake infrastructure:
LIBFOO_VERSION
, LIBFOO_SOURCE
, LIBFOO_PATCH
, LIBFOO_SITE
,
LIBFOO_SUBDIR
, LIBFOO_DEPENDENCIES
, LIBFOO_INSTALL_STAGING
,
LIBFOO_INSTALL_TARGET
.
A few additional variables, specific to the CMake infrastructure, can also be defined. Many of them are only useful in very specific cases, typical packages will therefore only use a few of them.
LIBFOO_SUBDIR
may contain the name of a subdirectory inside the
package that contains the main CMakeLists.txt file. This is useful,
if for example, the main CMakeLists.txt file is not at the root of
the tree extracted by the tarball. If HOST_LIBFOO_SUBDIR
is not
specified, it defaults to LIBFOO_SUBDIR
.
LIBFOO_CONF_ENV
, to specify additional environment variables to
pass to CMake. By default, empty.
LIBFOO_CONF_OPT
, to specify additional configure options to pass
to CMake. By default, empty.
LIBFOO_MAKE
, to specify an alternate make
command. This is
typically useful when parallel make is enabled in the configuration
(using BR2_JLEVEL
) but that this feature should be disabled for
the given package, for one reason or another. By default, set to
$(MAKE)
. If parallel building is not supported by the package,
then it should be set to LIBFOO_MAKE=$(MAKE1)
.
LIBFOO_MAKE_ENV
, to specify additional environment variables to
pass to make in the build step. These are passed before the make
command. By default, empty.
LIBFOO_MAKE_OPT
, to specify additional variables to pass to make
in the build step. These are passed after the make
command. By
default, empty.
LIBFOO_INSTALL_STAGING_OPT
contains the make options used to
install the package to the staging directory. By default, the value
is DESTDIR=$(STAGING_DIR) install
, which is correct for most
CMake packages. It is still possible to override it.
LIBFOO_INSTALL_TARGET_OPT
contains the make options used to
install the package to the target directory. By default, the value
is DESTDIR=$(TARGET_DIR) install
. The default value is correct
for most CMake packages, but it is still possible to override it if
needed.
LIBFOO_CLEAN_OPT
contains the make options used to clean the
package. By default, the value is clean
.
With the CMake infrastructure, all the steps required to build and install the packages are already defined, and they generally work well for most CMake-based packages. However, when required, it is still possible to customize what is done in any particular step:
.mk
file defines its own
LIBFOO_CONFIGURE_CMDS
variable, it will be used instead of the
default CMake one. However, using this method should be restricted
to very specific cases. Do not use it in the general case.
Many packages that support internationalization use the gettext library. Dependencies for this library are fairly complicated and therefore, deserve some explanation.
The uClibc C library doesn’t implement gettext functionality; therefore with this C library, a separate gettext must be compiled. On the other hand, the glibc C library does integrate its own gettext, and in this case the separate gettext library should not be compiled, because it creates various kinds of build failures.
Additionally, some packages (such as libglib2
) do require gettext
unconditionally, while other packages (those who support
--disable-nls
in general) only require gettext when locale support
is enabled.
Therefore, Buildroot defines two configuration options:
BR2_NEEDS_GETTEXT
, which is true as soon as the toolchain doesn’t
provide its own gettext implementation
BR2_NEEDS_GETTEXT_IF_LOCALE
, which is true if the toolchain
doesn’t provide its own gettext implementation and if locale support
is enabled
Packages that need gettext only when locale support is enabled should:
select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE
in the
Config.in
file;
$(if $(BR2_NEEDS_GETTEXT_IF_LOCALE),gettext)
in the package
DEPENDENCIES
variable in the .mk
file.
Packages that unconditionally need gettext (which should be very rare) should:
select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT
in the Config.in
file;
$(if $(BR2_NEEDS_GETTEXT),gettext)
in the package
DEPENDENCIES
variable in the .mk
file.
In Buildroot, there is some relationship between:
*.mk
file);
Config.in
file;
It is mandatory to maintain consistency between these elements, using the following rules:
*.mk
name are the package name
itself (e.g.: package/foo-bar_boo/foo-bar_boo.mk
);
foo-bar_boo
);
.
and -
characters substituted with _
, prefixed with BR2_PACKAGE_
(e.g.:
BR2_PACKAGE_FOO_BAR_BOO
);
*.mk
file variable prefix is the upper case package name
.
and -
characters substituted with _
(e.g.:
FOO_BAR_BOO_VERSION
).
Packages on github often don’t have a download area with release tarballs. However, it is possible to download tarballs directly from the repository on github.
If the package version matches a tag, then this tag should be used to identify the version:
FOO_VERSION = v1.0 FOO_SITE = http://github.com/<user>/<package>/tarball/$(FOO_VERSION)
If the package has no release version, or its version cannot be identified using tag, then the SHA1 of the particular commit should be used to identify the version (the first 7 characters of the SHA1 are enough):
FOO_VERSION = 1234567 FOO_SITE = http://github.com/<user>/<package>/tarball/<branch>
Note that the name of the tarball is the default foo-1234567.tar.gz
so it is not necessary to specify it in the .mk
file.
As you can see, adding a software package to Buildroot is simply a matter of writing a Makefile using an existing example and modifying it according to the compilation process required by the package.
If you package software that might be useful for other people, don’t forget to send a patch to the Buildroot mailing list (see Section 10.1, “Submitting patches”)!
While integrating a new package or updating an existing one, it may be necessary to patch the source of the software to get it cross-built within Buildroot.
Buildroot offers an infrastructure to automatically handle this during the builds. It supports three ways of applying patch sets: downloaded patches, patches supplied within buildroot and patches located in a user-defined global patch directory.
If it is necessary to apply a patch that is available for download, then it
to the <packagename>_PATCH
variable. It is downloaded from the same site
as the package itself. It can be a single patch, or a tarball containing a
patch series.
This method is typically used for packages from Debian.
Most patches are provided within Buildroot, in the package directory; these typically aim to fix cross-compilation, libc support, or other such issues.
These patch files should be named <packagename>-<number>-<description>.patch
.
A series
file, as used by quilt
, may also be added in the
package directory. In that case, the series
file defines the patch
application order.
Notes
<number>
in the patch file name refers to the apply order.
The BR2_GLOBAL_PATCH_DIR
configuration file option can be
used to specify a directory containing global package patches. See
Section 3.4.4, “Customizing packages” for details.
<packagename>_PRE_PATCH_HOOKS
commands if defined;
*.rej
files;
<packagename>_PATCH
is defined, then patches from these
tarballs are applied;
If there are some *.patch
files in the package directory or in the
a package subdirectory named <packageversion>
, then:
series
file exists in the package directory, then patches are
applied according to the series
file;
<packagename>-*.patch
are applied in alphabetical order.
So, to ensure they are applied in the right order, it is hightly
recommended to named the patch files like this:
<packagename>-<number>-<description>.patch
, where <number>
refers to the apply order.
<packagename>_POST_PATCH_HOOKS
commands if defined.
If something goes wrong in the steps 3 or 4, then the build fails.
Patches are released under the same license as the software that is modified.
A message explaining what the patch does, and why it is needed, should be added in the header commentary of the patch.
You should add a Signed-off-by
statement in the header of the each
patch to help with keeping track of the changes and to certify that the
patch is released under the same license as the software that is modified.
If the software is under version control, it is recommended to use the upstream SCM software to generate the patch set.
Otherwise, concatenate the header with the output of the
diff -purN package-version.orig/ package-version/
command.
At the end, the patch should look like:
configure.ac: add C++ support test signed-off-by John Doe <john.doe@noname.org> --- configure.ac.orig +++ configure.ac @@ -40,2 +40,12 @@ AC_PROG_MAKE_SET + +AC_CACHE_CHECK([whether the C++ compiler works], + [rw_cv_prog_cxx_works], + [AC_LANG_PUSH([C++]) + AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], + [rw_cv_prog_cxx_works=yes], + [rw_cv_prog_cxx_works=no]) + AC_LANG_POP([C++])]) + +AM_CONDITIONAL([CXX_WORKS], [test "x$rw_cv_prog_cxx_works" = "xyes"])
When integrating a patch of which you are not the author, you have to add a few things in the header of the patch itself.
Depending on whether the patch has been obtained from the project repository itself, or from somewhere on the web, add one of the following tags:
Backported from: <some commit id>
or
Fetch from: <some url>
It is also sensible to add a few words about any changes to the patch that may have been necessary.
All of the end products of Buildroot (toolchain, root filesystem, kernel, bootloaders) contain open source software, released under various licenses.
Using open source software gives you the freedom to build rich embedded systems, choosing from a wide range of packages, but also imposes some obligations that you must know and honour. Some licenses require you to publish the license text in the documentation of your product. Others require you to redistribute the source code of the software to those that receive your product.
The exact requirements of each license are documented in each package, and
it is your responsibility (or that of your legal office) to comply with those
requirements.
To make this easier for you, Buildroot can collect for you some material you
will probably need. To produce this material, after you have 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:
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.
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.
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. Certainly, more material is produced than is
needed for a strict legal compliance. For example, it produces the source code
for packages released under BSD-like licenses, that you are not required 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 (including patches to packages for which source
distribution is required).
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
:
GNU General Public License, version 2;
GPLv2+
:
GNU General Public License, version 2
or (at your option) any later version;
GPLv3
:
GNU General Public License, version 3;
GPLv3+
:
GNU General Public License, version 3
or (at your option) any later version;
GPL
:
GNU General Public License (any version);
LGPLv2
:
GNU Library General Public License, version 2;
LGPLv2+
:
GNU Library General Public License, version 2.1
or (at your option) any later version;
LGPLv2.1
:
GNU Lesser General Public License, version 2.1;
LGPLv2.1+
:
GNU Lesser General Public License, version 2.1
or (at your option) any later version;
LGPLv3
:
GNU Lesser General Public License, version 3;
LGPLv3+
:
GNU Lesser General Public License, version 3
or (at your option) any later version;
LGPL
:
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;
MIT
: MIT-style license.
Buildroot itself is an open source software, released under the 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 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 that this is only the Buildroot developers' opinion, and you should consult your legal department or lawyer in case of any doubt.
To achieve NFS-boot, enable tar root filesystem in the Filesystem images menu.
After a complete build, just run the following commands to setup the NFS-root directory:
sudo tar -xavf /path/to/output_dir/rootfs.tar -C /path/to/nfs_root_dir
Remember to add this path to /etc/exports
.
Then, you can execute a NFS-boot from your target.
If you want to chroot in a generated image, then there are few thing you should be aware of:
qemu-*
binary and correctly set it
within the binfmt
properties to be able to run the binaries built
for the target on your host machine;
host-qemu
and binfmt
correctly built and set for that kind of use.
Like any open source project, Buildroot has different ways to share information in its community and outside.
One piece of it is the document you are currently reading ;-).
Each of those ways may interest you if you are looking for some help, want to understand Buildroot or contribute to the project.
Buildroot has a mailing list http://lists.busybox.net/pipermail/buildroot for discussion and development.
You can subscribe by visiting http://lists.busybox.net/mailman/listinfo/buildroot. Only subscribers to the Buildroot mailing list are allowed to post to this list.
The list is also available through Gmane http://gmane.org, at
gmane.comp.lib.uclibc.buildroot
http://dir.gmane.org/gmane.comp.lib.uclibc.buildroot.
Please search the mailing list archives before asking questions on the mailing list, since there is a good chance someone else has asked the same question before. Checking the archives is a great way to avoid annoying everyone on the list with frequently asked questions…
The Buildroot IRC is irc://freenode.net/#buildroot.
The channel #buildroot
is hosted on Freenode
http://webchat.freenode.net.
When asking for help on IRC, share relevant logs or pieces of code using a code sharing website.
The Buildroot patch management interface is at http://patchwork.buildroot.org.
All patches and comments sent through the mailing list are automatically indexed in patchwork.
The Buildroot bugtracker is at https://bugs.busybox.net.
To open a bug, see Section 10.4, “Reporting issues/bugs, get help”.
After the Buildroot developer day on February 3, 2012, a page dedicated to Buildroot has been created on elinux.org.
This page is reachable at http://elinux.org/Buildroot.
Currently, this page is mainly used as a todo-list.
If you want to contribute to Buildroot, you will need a git view of the project. Refer to Section 2.2, “Getting Buildroot” to get it.
Currently, the mailing list is the central place for contribution. If you have not already subscribed to it, then refer to Section 9.1.1, “Subscribing to the mailing list”.
Recently, a web interface is also used to manage patches sent to the mailing list, see Section 9.3, “Patchwork”.
Please, do not attach patches to bugs, send them to the mailing list instead (see Section 10.1, “Submitting patches”).
When your changes are done, and committed in your local git view, rebase your development branch on top of the upstream tree before generating the patch set. To do so, run:
$ git fetch --all --tags $ git rebase origin/master
Here, you are ready to generate then submit your patch set.
To generate it, run:
$ git format-patch -M -n -s -o outgoing origin/master
This will generate patch files in the outgoing
subdirectory,
automatically adding the signed-off-by
line.
If you want to present the whole patch set in a separate mail, add
--cover-letter
to the previous command line (man git-format-patch
for further information).
Once patch files are generated, you can review/edit the commit message before submitting them using your favorite text editor.
Lastly, send/submit your patch set to the Buildroot mailing list:
$ git send-email --to buildroot@busybox.net outgoing/*
Note that git
should be configured to use your mail account.
To configure git
, see man git-send-email
or google it.
Make sure posted patches are not line-wrapped, otherwise they cannot
easily be applied. In such a case, fix your e-mail client, or better,
use git send-email
to send your patches.
In the review process, do not hesitate to respond to patch submissions for remarks, suggestions or anything that will help everyone to understand the patches and make them better.
Some tags are used to help following the state of any patch posted on the mailing-list:
The Buildroot community is currently setting up automatic builds in order to test more and more configurations. All build results are available at http://autobuild.buildroot.org
A good way to contribute is by fixing broken builds.
In the commit message of a patch fixing an autobuild, add a
reference to the build result directory (the dir
link in the data
column):
Fixes http://autobuild.buildroot.org/results/51000a9d4656afe9e0ea6f07b9f8ed374c2e4069
Before reporting any issue, please check the mailing list archive Section 9.1.1, “Subscribing to the mailing list” in case someone has already reported and fixed a similar problem.
However you choose to report bugs or get help, opening a bug Section 9.4, “Bugtracker” or send a mail to the mailing list Section 9.1.1, “Subscribing to the mailing list”, there are a number of details to provide in order to help people reproduce and find a solution to the issue.
Try to think as if you were trying to help someone else; in that case, what would you need?
Here is a short list of details to provide in such case:
Additionnally, your can add the .config
file.
If some of these details are too large, do not hesitate to use a pastebin service (see http://www.similarsitesearch.com/alternatives-to/pastebin.com).
The makedev syntax is used in several places in Buildroot to define changes to be made for permissions, or which device files to create and how to create them, in order to avoid calls to mknod.
This syntax is derived from the makedev utility, and more complete
documentation can be found in the package/makedevs/README
file.
It takes the form of a line for each file, with the following layout:
name | type | mode | uid | gid | major | minor | start | inc | count |
There are a few non-trivial blocks here:
name
is the path to the file you want to create/modify
type
is the type of the file, being one of:
mode
, uid
and gid
are the usual permissions settings
major
and minor
are here for device files - set to - for other
files
start
, inc
and count
are for when you want to create a batch
of files, and can be reduced to a loop, beginning at start
,
incrementing its counter by inc
until it reaches count
Let’s say you want to change the permissions of a given file; using this syntax, you will need to put:
/usr/bin/foobar f 644 0 0 - - - - -
On the other hand, if you want to create the device file /dev/hda
and the corresponding 15 files for the partitions, you will need for
/dev/hda
:
/dev/hda b 640 0 0 3 0 0 0 -
and then for device files corresponding to the partitions of
/dev/hda
, /dev/hdaX
, X
ranging from 1 to 15:
/dev/hda b 640 0 0 3 1 1 1 15
The syntax to create users is inspired by the makedev syntax, above, but is specific to Buildroot.
The syntax for adding a user is a space-separated list of fields, one user per line; the fields are:
username | uid | group | gid | password | home | shell | groups | comment |
Where:
username
is the desired user name (aka login name) for the user.
It can not be root
, and must be unique.
uid
is the desired UID for the user. It must be unique, and not
0
. If set to -1
, then a unique UID will be computed by Buildroot
in the range [1000…1999]
group
is the desired name for the user’s main group. It can not
be root
. If the group does not exist, it will be created.
gid
is the desired GID for the user’s main group. It must be unique,
and not 0
. If set to -1
, and the group does not already exist, then
a unique GID will be computed by Buildroot in the range [1000..1999]
password
is the crypt(3)-encoded password. If prefixed with !
,
then login is disabled. If prefixed with =
, then it is interpreted
as clear-text, and will be crypt-encoded (using MD5). If prefixed with
!=
, then the password will be crypt-encoded (using MD5) and login
will be disabled. If set to *
, then login is not allowed.
home
is the desired home directory for the user. If set to -, no
home directory will be created, and the user’s home will be /
.
Explicitly setting home
to /
is not allowed.
shell
is the desired shell for the user. If set to -
, then
/bin/false
is set as the user’s shell.
groups
is the comma-separated list of additional groups the user
should be part of. If set to -
, then the user will be a member of
no additional group. Missing groups will be created with an arbitrary
gid
.
comment
(aka GECOS
field) is an almost-free-form text.
There are a few restrictions on the content of each field:
comment
, all fields are mandatory.
comment
, fields may not contain spaces.
:
).
If home
is not -
, then the home directory, and all files below,
will belong to the user and its main group.
Examples:
foo -1 bar -1 !=blabla /home/foo /bin/sh alpha,bravo Foo user
This will create this user:
username
(aka login name) is: foo
uid
is computed by Buildroot
group
is: bar
gid
is computed by Buildroot
password
is: blabla
, will be crypt(3)-encoded, and login is disabled.
home
is: /home/foo
shell
is: /bin/sh
foo
is also a member of groups
: alpha
and bravo
comment
is: Foo user
test 8000 wheel -1 = - /bin/sh - Test user
This will create this user:
username
(aka login name) is: test
uid
is : 8000
group
is: wheel
gid
is computed by Buildroot, and will use the value defined in the rootfs skeleton
password
is empty (aka no password).
home
is /
but will not belong to test
shell
is: /bin/sh
test
is not a member of any additional groups
comment
is: Test user
Packages | Package Selection for the target → … |
---|---|
acl | → System tools |
acpid | → Hardware handling |
aircrack-ng | → Networking applications |
alsa-lib | → Libraries → Audio/Sound |
alsa-utils | → Audio and video applications |
alsamixergui | → Graphic libraries and applications (graphic/text) |
applewmproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
appres | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
apr | → Libraries → Other |
apr-util | → Libraries → Other |
argp-standalone | → Libraries → Other |
argus | → Networking applications |
arptables | → Networking applications |
at | → Shell and utilities |
atk | → Libraries → Graphics |
attr | → System tools |
audiofile | → Libraries → Audio/Sound |
aumix | → Audio and video applications |
autoconf (deprecated) | → Development tools |
automake (deprecated) | → Development tools |
avahi | → Networking applications |
axel | → Networking applications |
b43-firmware | → Hardware handling → Misc devices firmwares |
bash | → Shell and utilities |
bcusdk | → Networking applications |
bdftopcf | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
beecrypt | → Libraries → Crypto |
beforelight | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
bellagio | → Audio and video applications |
berkeleydb | → Libraries → Database |
bigreqsproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
bind | → Networking applications |
binutils | → Development tools |
bison | → Development tools |
bitmap | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
blackbox | → Graphic libraries and applications (graphic/text) |
bluez-utils | → Networking applications |
bmon | → Networking applications |
boa | → Networking applications |
bonnie++ | → Debugging, profiling and benchmark |
boost | → Libraries → Other |
bootutils | → System tools |
bridge-utils | → Networking applications |
bsdiff | → Development tools |
bustle | → Development tools |
BusyBox | |
bwm-ng | → System tools |
bzip2 | → Compressors and decompressors |
cache-calibrator | → Debugging, profiling and benchmark |
cairo | → Libraries → Graphics |
can-utils | → Networking applications |
ccache (deprecated) | → Development tools |
ccid | → Libraries → Hardware handling |
cdrkit | → Hardware handling |
cegui06 | → Graphic libraries and applications (graphic/text) |
cgilua | → Interpreter languages and scripting → LUA libraries/modules |
chrony | → Networking applications |
cifs-utils | → Filesystem and flash utilities |
cJSON | → Libraries → JSON/XML |
classpath | → Libraries → Other |
collectd | → Miscellaneous |
compositeproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
connman | → Networking applications |
conntrack-tools | → Networking applications |
copas | → Interpreter languages and scripting → LUA libraries/modules |
coreutils | → Development tools |
coxpcall | → Interpreter languages and scripting → LUA libraries/modules |
cpanminus | → Interpreter languages and scripting → Perl libraries/modules |
cppzmq | → Libraries → Networking |
cpuload | → System tools |
cramfs | → Filesystem and flash utilities |
crda | → Networking applications |
cryptodev support | → Libraries → Crypto |
cryptodev-linux | → Libraries → Crypto → cryptodev variant |
ctorrent | → Networking applications |
cups | → Networking applications |
curlftpfs (FUSE) | → Filesystem and flash utilities |
cvs | → Development tools |
czmq | → Libraries → Networking |
damageproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
dash | → Shell and utilities |
dbus | → Hardware handling |
dbus-glib | → Hardware handling |
dbus-python | → Hardware handling |
Declarative module | → Graphic libraries and applications (graphic/text) |
devmem2 | → Hardware handling |
dhcpdump | → Networking applications |
dhrystone | → Debugging, profiling and benchmark |
dialog | → Shell and utilities |
diffutils | → Development tools |
directfb | → Graphic libraries and applications (graphic/text) |
directfb examples | → Graphic libraries and applications (graphic/text) |
directfb virtual input extension | → Graphic libraries and applications (graphic/text) |
distcc | → Development tools |
dmalloc | → Debugging, profiling and benchmark |
dmidecode | → Hardware handling |
dmraid | → Hardware handling |
dmxproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
dnsmasq | → Networking applications |
docker | → Graphic libraries and applications (graphic/text) |
dosfstools | → Filesystem and flash utilities |
dri2proto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
dropbear | → Networking applications |
dsp-tools | → System tools |
dstat | → Debugging, profiling and benchmark |
dtach | → Shell and utilities |
dvb-apps (transponders data) | → Hardware handling |
dvbsnoop | → Hardware handling |
e2fsprogs | → Filesystem and flash utilities |
ebtables | → Networking applications |
ed | → Text editors and viewers |
editres | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
eeprog | → Hardware handling |
elfutils | → Libraries → Other |
empty | → Miscellaneous |
enchant | → Libraries → Text and terminal handling |
encodings | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
enlightenment | → Graphic libraries and applications (graphic/text) |
Enlightenment Foundation Libraries | → Graphic libraries and applications (graphic/text) |
enscript | → Interpreter languages and scripting |
erlang | → Interpreter languages and scripting |
ethtool | → Networking applications |
evtest | → Hardware handling |
exFAT (FUSE) | → Filesystem and flash utilities |
exfat-utils | → Filesystem and flash utilities |
expat | → Libraries → JSON/XML |
expedite | → Graphic libraries and applications (graphic/text) |
explorercanvas | → Libraries → Javascript |
ezxml | → Libraries → JSON/XML |
f2fs-tools | → Filesystem and flash utilities |
faad2 | → Audio and video applications |
fan-ctrl | → Hardware handling |
fb-test-app | → Graphic libraries and applications (graphic/text) |
fbdump (Framebuffer Capture Tool) | → Graphic libraries and applications (graphic/text) |
fbgrab | → Graphic libraries and applications (graphic/text) |
fbset | → Graphic libraries and applications (graphic/text) |
fbterm | → Graphic libraries and applications (graphic/text) |
fbv | → Graphic libraries and applications (graphic/text) |
fconfig | → Hardware handling |
feh | → Graphic libraries and applications (graphic/text) |
ffmpeg | → Audio and video applications |
fftw | → Libraries → Other |
file | → Shell and utilities |
filemq | → Libraries → Networking |
findutils | → Development tools |
firmware-imx | → Hardware handling → Misc devices firmwares |
fis | → Hardware handling |
fixesproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
flac | → Audio and video applications |
flashbench | → Filesystem and flash utilities |
flashrom | → Hardware handling |
flex | → Development tools |
flot | → Libraries → Javascript |
fltk | → Libraries → Graphics |
fluxbox | → Graphic libraries and applications (graphic/text) |
fmtools | → Hardware handling |
font-adobe-100dpi | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-adobe-75dpi | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-adobe-utopia-100dpi | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-adobe-utopia-75dpi | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-adobe-utopia-type1 | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-alias | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-arabic-misc | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-bh-100dpi | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-bh-75dpi | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-bh-lucidatypewriter-100dpi | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-bh-lucidatypewriter-75dpi | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-bh-ttf | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-bh-type1 | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-bitstream-100dpi | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-bitstream-75dpi | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-bitstream-type1 | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-cronyx-cyrillic | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-cursor-misc | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-daewoo-misc | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-dec-misc | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-ibm-type1 | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-isas-misc | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-jis-misc | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-micro-misc | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-misc-cyrillic | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-misc-ethiopic | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-misc-meltho | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-misc-misc | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-mutt-misc | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-schumacher-misc | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-screen-cyrillic | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-sony-misc | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-sun-misc | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-util | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-winitzki-cyrillic | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
font-xfree86-type1 | → Graphic libraries and applications (graphic/text) → X11R7 Fonts |
fontcacheproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
fontconfig | → Libraries → Graphics |
fontsproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
fonttosfnt | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
foomatic_filters | → Networking applications |
freerdp | → Graphic libraries and applications (graphic/text) |
freetype | → Libraries → Graphics |
fslsfonts | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
fstobdf | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
fxload | → Hardware handling |
gadgetfs-test | → Hardware handling |
gamin | → Libraries → Filesystem |
gawk | → Development tools |
gd | → Libraries → Graphics |
gdb | → Debugging, profiling and benchmark |
gdbm | → Libraries → Database |
gdk-pixbuf | → Libraries → Graphics |
genext2fs | → Filesystem and flash utilities |
genromfs | → Filesystem and flash utilities |
gesftpserver | → Networking applications |
gettext | → Development tools |
giblib | → Libraries → Graphics |
glib-networking | → Libraries → Networking |
glibmm | → Libraries → Other |
glproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
gmp | → Libraries → Other |
gmpc | → Graphic libraries and applications (graphic/text) |
gnuchess | → Games |
gnupg | → Shell and utilities |
gnuplot | → Graphic libraries and applications (graphic/text) |
gnutls | → Libraries → Crypto |
gob2 | → Graphic libraries and applications (graphic/text) |
Google font directory | → Miscellaneous |
gperf | → Development tools |
gpsd | → Hardware handling |
gptfdisk | → Hardware handling |
gqview | → Graphic libraries and applications (graphic/text) |
grantlee | → Graphic libraries and applications (graphic/text) |
grep | → Development tools |
gsl | → Libraries → Other |
gst-dsp | → Audio and video applications |
gst-ffmpeg | → Audio and video applications |
gst-fsl-plugins | → Audio and video applications |
gst-omapfb | → Audio and video applications |
gst-plugins-bad | → Audio and video applications |
gst-plugins-base | → Audio and video applications |
gst-plugins-good | → Audio and video applications |
gst-plugins-ugly | → Audio and video applications |
gstreamer | → Audio and video applications |
gtest | → Libraries → Other |
gtk engines | → Libraries → Graphics |
gtkperf (performance test for GTK2) | → Graphic libraries and applications (graphic/text) |
gutenprint | → Networking applications |
gvfs | → Hardware handling |
gzip | → Compressors and decompressors |
haserl | → Interpreter languages and scripting |
hdparm | → Hardware handling |
heirloom-mailx | → Networking applications |
hiawatha | → Networking applications |
hicolor (default theme) | → Libraries → Graphics → GTK Themes |
hostapd | → Networking applications |
hplip | → Networking applications |
htop | → System tools |
httping | → Networking applications |
hwdata | → Hardware handling |
i2c-tools | → Hardware handling |
iceauth | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
ico | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
icu | → Libraries → Text and terminal handling |
ifplugd | → Networking applications |
iftop | → Networking applications |
igh-ethercat | → Networking applications |
imagemagick | → Graphic libraries and applications (graphic/text) |
imlib2 | → Libraries → Graphics |
imx-lib | → Libraries → Hardware handling |
inadyn | → Networking applications |
infozip | → Compressors and decompressors |
inotify-tools | → Shell and utilities |
input-event-daemon | → Hardware handling |
input-tools | → Hardware handling |
inputproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
intltool | → Development tools |
iostat | → Hardware handling |
iozone | → Debugging, profiling and benchmark |
iperf | → Networking applications |
ipkg | → Package managers |
iproute2 | → Networking applications |
ipsec-tools | → Networking applications |
ipset | → Networking applications |
iptables | → Networking applications |
irda-utils | → Hardware handling |
isc dhcp | → Networking applications |
iw | → Networking applications |
jamvm | → Interpreter languages and scripting |
jansson | → Libraries → JSON/XML |
jhead | → Graphic libraries and applications (graphic/text) |
jpeg | → Libraries → Graphics → jpeg variant |
jpeg support | → Libraries → Graphics |
jpeg-turbo | → Libraries → Graphics → jpeg variant |
jQuery | → Libraries → Javascript |
jQuery keyboard | → Libraries → Javascript |
jQuery UI | → Libraries → Javascript |
jQuery UI themes | → Libraries → Javascript |
jQuery-Sparkline | → Libraries → Javascript |
jQuery-Validation | → Libraries → Javascript |
jsmin | → Libraries → Javascript |
json-c | → Libraries → JSON/XML |
json-glib | → Libraries → JSON/XML |
json-javascript | → Libraries → Javascript |
kbd | → Hardware handling |
kbproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
kexec | → Debugging, profiling and benchmark |
keyutils | → System tools |
kismet | → Networking applications |
kmod | → System tools |
lame | → Audio and video applications |
latencytop | → Debugging, profiling and benchmark |
lcdapi | → Libraries → Hardware handling |
lcdproc | → Hardware handling |
lcms2 | → Libraries → Graphics |
leafpad | → Graphic libraries and applications (graphic/text) |
less | → Text editors and viewers |
libaio | → Libraries → Hardware handling |
libao | → Libraries → Audio/Sound |
libarchive | → Libraries → Compression and decompression |
libargtable2 | → Libraries → Other |
libart | → Libraries → Graphics |
libatasmart | → Libraries → Hardware handling |
libatomic_ops | → Libraries → Other |
libcap | → Libraries → Other |
libcap-ng | → Libraries → Other |
libcdaudio | → Libraries → Audio/Sound |
libcgi | → Libraries → Networking |
libcgicc | → Libraries → Networking |
libcofi | → Libraries → Other |
libconfig | → Libraries → Filesystem |
libconfuse | → Libraries → Filesystem |
libcue | → Libraries → Audio/Sound |
libcuefile | → Libraries → Audio/Sound |
libcurl | → Libraries → Networking |
libdaemon | → Libraries → Other |
libdmtx | → Libraries → Graphics |
libdmx | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libdnet | → Libraries → Networking |
libdrm | → Libraries → Graphics |
libdvdnav | → Libraries → Multimedia |
libdvdread | → Libraries → Multimedia |
libebml | → Libraries → Multimedia |
libecore | → Graphic libraries and applications (graphic/text) |
libedbus | → Graphic libraries and applications (graphic/text) |
libedje | → Graphic libraries and applications (graphic/text) |
libeet | → Graphic libraries and applications (graphic/text) |
libefreet | → Graphic libraries and applications (graphic/text) |
libeina | → Graphic libraries and applications (graphic/text) |
libeio | → Graphic libraries and applications (graphic/text) |
libelementary | → Graphic libraries and applications (graphic/text) |
libelf | → Libraries → Other |
libembryo | → Graphic libraries and applications (graphic/text) |
Liberation (Free fonts) | → Graphic libraries and applications (graphic/text) |
libesmtp | → Libraries → Networking |
libethumb | → Graphic libraries and applications (graphic/text) |
libev | → Libraries → Other |
libevas | → Graphic libraries and applications (graphic/text) |
libevas generic loaders | → Graphic libraries and applications (graphic/text) |
libevent | → Libraries → Other |
libexif | → Libraries → Graphics |
libeXosip2 | → Libraries → Networking |
libfcgi | → Libraries → Networking |
libffi | → Libraries → Other |
libfontenc | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libfreefare | → Libraries → Hardware handling |
libfribidi | → Libraries → Text and terminal handling |
libFS | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libfslcodec | → Libraries → Multimedia |
libfslparser | → Libraries → Multimedia |
libfslvpuwrap | → Libraries → Multimedia |
libftdi | → Libraries → Hardware handling |
libfuse | → Libraries → Filesystem |
libgail | → Libraries → Graphics |
libgcrypt | → Libraries → Crypto |
libgeotiff | → Libraries → Graphics |
libglade | → Libraries → Graphics |
libglib2 | → Libraries → Other |
libgpg-error | → Libraries → Crypto |
libgsasl | → Libraries → Networking |
libgtk2 | → Libraries → Graphics |
libhid | → Libraries → Hardware handling |
libical | → Libraries → Other |
libICE | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libiconv | → Libraries → Text and terminal handling |
libid3tag | → Libraries → Audio/Sound |
libidn | → Libraries → Networking |
libiqrf | → Libraries → Hardware handling |
libiscsi | → Libraries → Networking |
libjson | → Libraries → JSON/XML |
liblo | → Libraries → Audio/Sound |
liblockfile | → Libraries → Filesystem |
liblog4c-localtime | → Libraries → Other |
libmad | → Libraries → Audio/Sound |
libmatroska | → Libraries → Multimedia |
libmbus | → Libraries → Networking |
libmcrypt | → Libraries → Crypto |
libmhash | → Libraries → Crypto |
libmicrohttpd | → Libraries → Networking |
libmms | → Libraries → Multimedia |
libmnl | → Libraries → Networking |
libmodbus | → Libraries → Networking |
libmpd | → Libraries → Audio/Sound |
libmpeg2 | → Libraries → Multimedia |
libneon | → Libraries → Networking |
libnetfilter_acct | → Libraries → Networking |
libnetfilter_conntrack | → Libraries → Networking |
libnetfilter_cthelper | → Libraries → Networking |
libnetfilter_cttimeout | → Libraries → Networking |
libnetfilter_log | → Libraries → Networking |
libnetfilter_queue | → Libraries → Networking |
libnfc | → Libraries → Hardware handling |
libnfc-llcp | → Libraries → Hardware handling |
libnfnetlink | → Libraries → Networking |
libnl | → Libraries → Networking |
libnspr | → Libraries → Other |
libnss | → Libraries → Crypto |
liboauth | → Libraries → Networking |
libogg | → Libraries → Multimedia |
liboping | → Libraries → Networking |
libosip2 | → Libraries → Networking |
libpcap | → Libraries → Networking |
libpciaccess | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libpfm4 | → Libraries → Other |
libplayer | → Libraries → Multimedia |
libpng | → Libraries → Graphics |
libpthread-stubs | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libpthsem | → Libraries → Other |
libraw | → Libraries → Graphics |
libraw1394 | → Libraries → Hardware handling |
libreplaygain | → Libraries → Audio/Sound |
librsvg | → Libraries → Graphics |
librsync | → Libraries → Networking |
libsamplerate | → Libraries → Audio/Sound |
libseccomp | → Libraries → Other |
libserial | → Libraries → Hardware handling |
libsexy | → Graphic libraries and applications (graphic/text) |
libsha1 | → Libraries → Crypto |
libsigc++ | → Libraries → Other |
libsigsegv | → Libraries → Other |
libSM | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libsndfile | → Libraries → Audio/Sound |
libsoup | → Libraries → Networking |
libsvgtiny | → Libraries → Graphics |
libsysfs | → Libraries → Filesystem |
libtasn1 | → Libraries → Other |
libtheora | → Libraries → Multimedia |
libtirpc | → Libraries → Networking |
libtool | → Development tools |
libtorrent | → Libraries → Networking |
libtpl | → Libraries → Other |
libungif | → Libraries → Graphics |
libupnp | → Libraries → Networking |
liburcu | → Libraries → Other |
libusb | → Libraries → Hardware handling |
libusb-compat | → Libraries → Hardware handling |
libv4l | → Libraries → Hardware handling |
libvncserver | → Libraries → Networking |
libvorbis | → Libraries → Audio/Sound |
libwebsockets | → Libraries → Networking |
libX11 | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXau | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXaw | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libxcb | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXcomposite | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXcursor | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXdamage | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXdmcp | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXext | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXfixes | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXfont | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXft | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXi | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXinerama | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libxkbcommon | → Libraries → Hardware handling |
libxkbfile | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libxml++ | → Libraries → JSON/XML |
libxml-parser-perl | → Libraries → JSON/XML |
libxml2 | → Libraries → JSON/XML |
libXmu | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXpm | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXrandr | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXrender | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXres | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXScrnSaver | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libxslt | → Libraries → JSON/XML |
libXt | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXtst | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXv | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXvMC | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXxf86dga | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libXxf86vm | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
libyaml | → Libraries → JSON/XML |
lighttpd | → Networking applications |
linenoise | → Libraries → Text and terminal handling |
linknx | → Networking applications |
links | → Networking applications |
linphone | → Networking applications |
linux-firmware | → Hardware handling → Misc devices firmwares |
linux-fusion communication layer for DirectFB multi | → Graphic libraries and applications (graphic/text) |
linux-pam | → Libraries → Other |
listres | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
LiTE (toolbox engine) | → Graphic libraries and applications (graphic/text) |
live555 | → Libraries → Multimedia |
lm-sensors | → Hardware handling |
lmbench | → Debugging, profiling and benchmark |
lockfile programs | → Shell and utilities |
log4cxx | → Libraries → Other |
logrotate | → Shell and utilities |
logsurfer | → Shell and utilities |
lrzsz | → Networking applications |
lshw | → Hardware handling |
lsof | → Debugging, profiling and benchmark |
lsuio | → Hardware handling |
ltp-testsuite | → Debugging, profiling and benchmark |
ltrace | → Debugging, profiling and benchmark |
lttng-babeltrace | → Debugging, profiling and benchmark |
lttng-libust | → Libraries → Other |
lttng-modules | → Debugging, profiling and benchmark |
lttng-tools | → Debugging, profiling and benchmark |
lua | → Interpreter languages and scripting |
lua-msgpack-native | → Interpreter languages and scripting → LUA libraries/modules |
luacjson | → Interpreter languages and scripting → LUA libraries/modules |
luaexpat | → Interpreter languages and scripting → LUA libraries/modules |
luafilesystem | → Interpreter languages and scripting → LUA libraries/modules |
luajit | → Interpreter languages and scripting |
luasocket | → Interpreter languages and scripting → LUA libraries/modules |
luit | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
lvm2 & device mapper | → Hardware handling |
lzma (deprecated) | → Compressors and decompressors |
lzo | → Libraries → Compression and decompression |
lzop | → Compressors and decompressors |
m4 | → Development tools |
macchanger | → Networking applications |
madplay | → Audio and video applications |
make | → Development tools |
makedepend | → Graphic libraries and applications (graphic/text) → X11R7 Utilities |
makedevs | → Filesystem and flash utilities |
Matchbox Desktop | → Graphic libraries and applications (graphic/text) |
Matchbox Panel | → Graphic libraries and applications (graphic/text) |
Matchbox session common files | → Graphic libraries and applications (graphic/text) |
Matchbox Virtual Keyboard | → Graphic libraries and applications (graphic/text) |
MatchBox Window Manager | → Graphic libraries and applications (graphic/text) |
mcookie | → Graphic libraries and applications (graphic/text) → X11R7 Utilities |
mcrypt | → Miscellaneous |
mdadm | → Hardware handling |
media-ctl | → Hardware handling |
mediastreamer | → Libraries → Multimedia |
memstat | → Debugging, profiling and benchmark |
memtester | → Hardware handling |
Mesa 3D Graphics Library | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
metacity | → Graphic libraries and applications (graphic/text) |
midori | → Graphic libraries and applications (graphic/text) |
mii-diag | → Networking applications |
Mini-XML | → Libraries → JSON/XML |
minicom | → Hardware handling |
mkfontdir | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
mkfontscale | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
mobile-broadband-provider-info | → Miscellaneous |
module-init-tools | → System tools |
mongoose | → Networking applications |
mongrel2 | → Networking applications |
monit | → System tools |
mpc | → Libraries → Other |
mpd | → Audio and video applications |
mpfr | → Libraries → Other |
mpg123 | → Audio and video applications |
mplayer | → Audio and video applications |
mrouted | → Networking applications |
msmtp | → Networking applications |
mtd/jffs2 utilities | → Filesystem and flash utilities |
mtdev | → Libraries → Hardware handling |
mtdev2tuio | → Libraries → Other |
Multimedia Module | → Graphic libraries and applications (graphic/text) |
musepack | → Audio and video applications |
mutt | → Networking applications |
MySQL client | → Libraries → Database |
nano | → Text editors and viewers |
nanocom | → Hardware handling |
nbd | → Networking applications |
ncdu | → System tools |
ncftp | → Networking applications |
ncurses | → Libraries → Text and terminal handling |
ndisc6 tools | → Networking applications |
ne10 | → Libraries → Hardware handling |
neard | → Hardware handling |
neardal | → Libraries → Hardware handling |
netatalk | → Networking applications |
netcat | → Networking applications |
netkitbase (deprecated) | → Networking applications |
netkittelnet (deprecated) | → Networking applications |
netperf | → Debugging, profiling and benchmark |
netplug | → Networking applications |
netsnmp | → Networking applications |
netstat-nat | → Networking applications |
nettle | → Libraries → Crypto |
NetworkManager | → Networking applications |
newt | → Libraries → Text and terminal handling |
nfacct | → Networking applications |
nfs-utils | → Filesystem and flash utilities |
ngircd | → Networking applications |
ngrep | → Networking applications |
nmap | → Networking applications |
nodejs | → Interpreter languages and scripting |
noip | → Networking applications |
nss-mdns | → Libraries → Networking |
ntfs-3g | → Filesystem and flash utilities |
ntp | → Networking applications |
nuttcp | → Networking applications |
ocf-linux | → Libraries → Crypto → cryptodev variant |
oclock | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
ofono | → Hardware handling |
OLSR mesh networking Daemon | → Networking applications |
open2300 | → Hardware handling |
opencv | → Libraries → Graphics |
openntpd | → Networking applications |
openobex | → Networking applications |
openocd | → Hardware handling |
openpgm | → Libraries → Networking |
openssh | → Networking applications |
openssl | → Libraries → Crypto |
openswan | → Networking applications |
openvpn | → Networking applications |
opkg | → Package managers |
oprofile | → Debugging, profiling and benchmark |
opus | → Libraries → Audio/Sound |
opus-tools | → Audio and video applications |
orc | → Libraries → Other |
oRTP | → Libraries → Networking |
owl-linux | → Hardware handling |
pango | → Libraries → Graphics |
parted | → Hardware handling |
patch | → Development tools |
pciutils | → Hardware handling |
pcmanfm | → Graphic libraries and applications (graphic/text) |
pcre | → Libraries → Text and terminal handling |
pcsc-lite | → Libraries → Hardware handling |
perf | → Debugging, profiling and benchmark |
perl | → Interpreter languages and scripting |
php | → Interpreter languages and scripting |
picocom | → Hardware handling |
pixman | → Libraries → Graphics |
pkg-config (deprecated) | → Development tools |
pkgconf | → Development tools |
poco | → Libraries → Other |
polarssl | → Libraries → Crypto |
polkit | → System tools |
poppler | → Libraries → Graphics |
popt | → Libraries → Text and terminal handling |
portaudio | → Libraries → Audio/Sound |
portmap | → Networking applications |
pppd | → Networking applications |
pptp-linux | → Networking applications |
PrBoom | → Games |
procps | → System tools |
proftpd | → Networking applications |
protobuf | → Libraries → Other |
protobuf-c | → Libraries → Other |
proxychains-ng | → Networking applications |
psmisc | → System tools |
pulseaudio | → Audio and video applications |
pv | → Debugging, profiling and benchmark |
pygame | → Interpreter languages and scripting → external python modules |
pyparsing | → Interpreter languages and scripting → external python modules |
python | → Interpreter languages and scripting |
python-bottle | → Interpreter languages and scripting → external python modules |
python-dpkt | → Interpreter languages and scripting → external python modules |
python-id3 | → Interpreter languages and scripting → external python modules |
python-mad | → Interpreter languages and scripting → external python modules |
python-meld3 | → Interpreter languages and scripting → external python modules |
python-netifaces | → Interpreter languages and scripting → external python modules |
python-nfc | → Interpreter languages and scripting → external python modules |
python-protobuf | → Interpreter languages and scripting → external python modules |
python-serial | → Interpreter languages and scripting → external python modules |
python-setuptools | → Interpreter languages and scripting → external python modules |
python-thrift | → Interpreter languages and scripting → external python modules |
python3 | → Interpreter languages and scripting |
qextserialport | → Graphic libraries and applications (graphic/text) |
qjson | → Graphic libraries and applications (graphic/text) |
Qt | → Graphic libraries and applications (graphic/text) |
Qt5 | → Graphic libraries and applications (graphic/text) |
qt5base | → Graphic libraries and applications (graphic/text) |
qt5declarative | → Graphic libraries and applications (graphic/text) |
qt5graphicaleffects | → Graphic libraries and applications (graphic/text) |
qt5imageformats | → Graphic libraries and applications (graphic/text) |
qt5jsbackend | → Graphic libraries and applications (graphic/text) |
qt5multimedia | → Graphic libraries and applications (graphic/text) |
qt5quick1 | → Graphic libraries and applications (graphic/text) |
qt5script | → Graphic libraries and applications (graphic/text) |
qt5svg | → Graphic libraries and applications (graphic/text) |
qt5webkit | → Graphic libraries and applications (graphic/text) |
qt5xmlpatterns | → Graphic libraries and applications (graphic/text) |
qtuio | → Graphic libraries and applications (graphic/text) |
quagga | → Networking applications |
quota | → System tools |
qwt | → Graphic libraries and applications (graphic/text) |
radvd | → Networking applications |
ramspeed | → Debugging, profiling and benchmark |
randrproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
rapidjson | → Libraries → JSON/XML |
rdesktop | → Graphic libraries and applications (graphic/text) |
read-edid | → Hardware handling |
readline | → Libraries → Text and terminal handling |
recordproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
redis | → Libraries → Database |
renderproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
resourceproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
rgb | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
rings | → Interpreter languages and scripting → LUA libraries/modules |
rng-tools | → Hardware handling |
roxml | → Libraries → JSON/XML |
rp-pppoe | → Networking applications |
rpcbind | → Networking applications |
rpi-firmware | → Hardware handling → Misc devices firmwares |
rpi-userland | → Hardware handling |
rpm | → Package managers |
rrdtool | → Graphic libraries and applications (graphic/text) |
rsh-redone | → Networking applications |
rstart | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
rsync | → Networking applications |
rsyslog | → System tools |
rt-tests | → Debugging, profiling and benchmark |
rtai | → Real-Time |
rtorrent | → Networking applications |
rubix | → Games |
ruby | → Interpreter languages and scripting |
samba | → Networking applications |
sane-backends | → Hardware handling |
SawMan (Window Manager) | → Graphic libraries and applications (graphic/text) |
schifra | → Libraries → Other |
sconeserver | → Networking applications |
screen | → Shell and utilities |
Script Module | → Graphic libraries and applications (graphic/text) |
scripts | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
scrnsaverproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
SDL | → Graphic libraries and applications (graphic/text) |
SDL_gfx | → Graphic libraries and applications (graphic/text) |
SDL_image | → Graphic libraries and applications (graphic/text) |
SDL_mixer | → Graphic libraries and applications (graphic/text) |
SDL_net | → Graphic libraries and applications (graphic/text) |
SDL_sound | → Graphic libraries and applications (graphic/text) |
SDL_TTF | → Graphic libraries and applications (graphic/text) |
sdparm | → Hardware handling |
sed | → Development tools |
ser2net | → Networking applications |
sessreg | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
setserial | → Hardware handling |
setxkbmap | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
sg3-utils | → Hardware handling |
shared-mime-info | → Miscellaneous |
shareware Doom WAD file | → Games |
showfont | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
slang | → Libraries → Text and terminal handling |
slirp | → Libraries → Networking |
smartmontools | → Hardware handling |
smproxy | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
snowball-hdmiservice | → Hardware handling |
snowball-init | → Miscellaneous |
socat | → Networking applications |
socketcand | → Networking applications |
sound-theme-borealis | → Miscellaneous |
sound-theme-freedesktop | → Miscellaneous |
spawn-fcgi | → Networking applications |
speex | → Libraries → Audio/Sound |
spice protocol | → Networking applications |
spice server | → Networking applications |
sqlcipher | → Libraries → Database |
sqlite | → Libraries → Database |
squashfs | → Filesystem and flash utilities |
squashfs3 (deprecated) | → Filesystem and flash utilities |
squid | → Networking applications |
sredird | → Hardware handling |
sshfs (FUSE) | → Filesystem and flash utilities |
sstrip | → Development tools |
startup-notification | → Libraries → Other |
statserial | → Hardware handling |
strace | → Debugging, profiling and benchmark |
stress | → Debugging, profiling and benchmark |
stunnel | → Networking applications |
sudo | → Shell and utilities |
supervisor | → System tools |
SVG Module | → Graphic libraries and applications (graphic/text) |
sylpheed | → Graphic libraries and applications (graphic/text) |
synergy | → Graphic libraries and applications (graphic/text) |
syslogd & klogd | → System tools |
sysprof | → Debugging, profiling and benchmark |
sysstat | → Hardware handling |
systemd | → System tools |
sysvinit | → System tools |
taglib | → Libraries → Audio/Sound |
tar | → Development tools |
tcl | → Interpreter languages and scripting |
tcllib | → Interpreter languages and scripting → tcl libraries/modules |
tcpdump | → Networking applications |
tcpreplay | → Networking applications |
tftpd | → Networking applications |
thttpd | → Networking applications |
ti-utils | → Hardware handling |
tidsp-binaries | → Audio and video applications |
tiff | → Libraries → Graphics |
time | → Shell and utilities |
tinyhttpd | → Networking applications |
tn5250 | → Networking applications |
torsmo | → Graphic libraries and applications (graphic/text) |
transmission | → Networking applications |
tremor (fixed point vorbis decoder) | → Libraries → Audio/Sound |
tslib | → Libraries → Hardware handling |
ttcp (deprecated) | → Networking applications |
tvheadend | → Networking applications |
twm | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
tzdata | → Libraries → Other |
u-boot tools | → Hardware handling |
udev | → Hardware handling |
udisks | → Hardware handling |
udpcast | → Networking applications |
uemacs | → Text editors and viewers |
ulogd | → Networking applications |
unionfs (FUSE) | → Filesystem and flash utilities |
urg | → Libraries → Hardware handling |
usb_modeswitch | → Hardware handling |
usb_modeswitch_data | → Hardware handling |
usbmount | → Hardware handling |
usbredir | → Libraries → Networking |
usbutils | → Hardware handling |
ushare | → Networking applications |
ussp-push | → Networking applications |
util-linux | → System tools |
util-macros | → Graphic libraries and applications (graphic/text) → X11R7 Utilities |
ux500-firmware | → Hardware handling → Misc devices firmwares |
vala (deprecated) | → Development tools |
valgrind | → Debugging, profiling and benchmark |
vde2 | → Networking applications |
videoproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
viewres | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
vim | → Text editors and viewers |
vorbis-tools | → Audio and video applications |
vpnc | → Networking applications |
vsftpd | → Networking applications |
vtun | → Networking applications |
wavpack | → Audio and video applications |
wayland | → Libraries → Graphics |
webkit | → Libraries → Graphics |
WebKit Module | → Graphic libraries and applications (graphic/text) |
webp | → Libraries → Graphics |
webrtc-audio-processing | → Libraries → Audio/Sound |
weston | → Graphic libraries and applications (graphic/text) |
wget | → Networking applications |
whetstone | → Debugging, profiling and benchmark |
which | → Shell and utilities |
windowswmproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
wipe | → Hardware handling |
wireless tools | → Networking applications |
wireless-regdb | → Networking applications |
wireshark | → Networking applications |
wpa_supplicant | → Networking applications |
wsapi | → Interpreter languages and scripting → LUA libraries/modules |
wvdial | → Networking applications |
wvstreams | → Libraries → Networking |
x11perf | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
x11vnc | → Graphic libraries and applications (graphic/text) |
xauth | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xavante | → Interpreter languages and scripting → LUA libraries/modules |
xbacklight | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xbiff | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xbitmaps | → Graphic libraries and applications (graphic/text) → X11R7 Other data |
xcalc | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xcb-proto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
xcb-util | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
xcb-util-image | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
xcb-util-keysyms | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
xcb-util-wm | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
xclipboard | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xclock | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xcmiscproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
xcmsdb | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xcursor-transparent-theme | → Graphic libraries and applications (graphic/text) → X11R7 Other data |
xcursorgen | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xdata_xcursor-themes | → Graphic libraries and applications (graphic/text) → X11R7 Other data |
xdbedizzy | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xditview | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xdm | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xdpyinfo | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xdriinfo | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xedit | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
Xenomai Userspace | → Real-Time |
xerces-c++ | → Libraries → JSON/XML |
xev | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xextproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
xeyes | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xf86-input-evdev | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-input-joystick | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-input-keyboard | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-input-mouse | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-input-synaptics | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-input-tslib | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-input-vmmouse | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-input-void | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-ark | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-ast | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-ati | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-cirrus | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-dummy | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-fbdev | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-geode | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-glide | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-glint | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-i128 | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-intel | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-mach64 | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-mga | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-neomagic | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-newport | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-nv | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-openchrome | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-r128 | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-savage | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-siliconmotion | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-sis | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-tdfx | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-tga | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-trident | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-v4l | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-vesa | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-vmware | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-voodoo | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86-video-wsfb | → Graphic libraries and applications (graphic/text) → X11R7 Drivers |
xf86bigfontproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
xf86dga | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xf86dgaproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
xf86driproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
xf86vidmodeproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
xfd | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xfontsel | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xfs | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xfsinfo | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xfsprogs | → Filesystem and flash utilities |
xgamma | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xgc | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xhost | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xineramaproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
xinetd | → Networking applications |
xinit | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xinput | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xinput-calibrator | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xkbcomp | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xkbevd | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xkbprint | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xkbutils | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xkeyboard-config | → Graphic libraries and applications (graphic/text) |
xkill | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xl2tp | → Networking applications |
xload | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xlogo | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xlsatoms | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xlsclients | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xlsfonts | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xmag | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xman | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xmessage | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xmh | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
XML Patterns Module | → Graphic libraries and applications (graphic/text) |
xmlstarlet | → Shell and utilities |
xmodmap | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xmore | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xorg-server | → Graphic libraries and applications (graphic/text) → X11R7 Servers |
xpr | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xprop | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xproto | → Graphic libraries and applications (graphic/text) → X11R7 X protocols |
xrandr | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xrdb | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xrefresh | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xset | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xsetmode | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xsetpointer | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xsetroot | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xsm | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xstdcmap | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xstroke (deprecated) | → Graphic libraries and applications (graphic/text) |
xterm | → Graphic libraries and applications (graphic/text) |
xtrans | → Graphic libraries and applications (graphic/text) → X11R7 Libraries |
xvidtune | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xvinfo | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xvkbd | → Graphic libraries and applications (graphic/text) |
xwd | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xwininfo | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xwud | → Graphic libraries and applications (graphic/text) → X11R7 Applications |
xz-utils | → Compressors and decompressors |
yajl | → Libraries → JSON/XML |
yasm | → Development tools |
yavta | → Audio and video applications |
zd1211-firmware | → Hardware handling → Misc devices firmwares |
zeromq | → Libraries → Networking |
zlib | → Libraries → Compression and decompression |
zmqpp | → Libraries → Networking |
zxing | → Libraries → Graphics |
zyre | → Libraries → Networking |
The following packages are all available in the menu Host utilities
.
Packages |
---|
host dfu-util |
host dosfstools |
host e2fsprogs |
host genimage |
host genpart |
host lpc3250loader |
host mtools |
host omap-u-boot-utils |
host openocd |
host sam-ba |
host u-boot tools |
The following features are marked as deprecated in Buildroot due to their status either too old or unmaintained.
Features | Location |
---|---|
documentation on the target | Build options |
development files in target filesystem | Build options |
Crosstool-NG toolchain | Toolchain → Toolchain type |
Linux 3.1.x kernel headers | Toolchain → Kernel Headers |
Linux 3.3.x kernel headers | Toolchain → Kernel Headers |
Linux 3.5.x kernel headers | Toolchain → Kernel Headers |
Linux 3.6.x kernel headers | Toolchain → Kernel Headers |
Linux 3.7.x kernel headers | Toolchain → Kernel Headers |
uClibc 0.9.31.x | Toolchain → uClibc C library Version |
gdb 7.2.x | Toolchain → GDB debugger Version |
gdb 7.3.x | Toolchain → GDB debugger Version |
lzma | Package Selection for the target → Compressors and decompressors |
autoconf | Package Selection for the target → Development tools |
automake | Package Selection for the target → Development tools |
ccache | Package Selection for the target → Development tools |
gcc | Package Selection for the target → Development tools |
pkg-config | Package Selection for the target → Development tools |
vala | Package Selection for the target → Development tools |
xstroke | Package Selection for the target → Graphic libraries and applications (graphic/text) |
squashfs3 | Package Selection for the target → Filesystem and flash utilities |
netkitbase | Package Selection for the target → Networking applications |
netkittelnet | Package Selection for the target → Networking applications |
ttcp | Package Selection for the target → Networking applications |
3.x | Filesystem images → SquashFS version |