Chapter9 Reference

Table of Contents

autotools class
oe_runconf / autotools_do_configure
Presetting autoconf variables (the site file)
binconfig class
Directories: Installation variables
Directories: Staging variables
distutils class
fakeroot (device node handling)
How fakeroot works
Root filesystem, images and fakeroot
Recipes and fakeroot
image class
Special node handling (fakeroot)
Device (/dev) nodes
Image types
Package feeds
Image types
Defining images
Available image types
Custom image types
pkgconfig class
rootfs_ipkg class
SECTION variable: Package category
siteinfo class
CONFIG_SITE: The autoconf site files
SRC_URI variable: Source code and patches
http/https/ftp (wget)
file: for patches and additional files
Manipulating SRC_URI
Source distribution (src_distribute_local)
update-alternatives class
Naming of the alternative commands
How alternatives work
The update-alternatives command
Priority of the alternatives
Tracking of the installed alternatives
Using the update-alternatives class
update-rc.d class
Multiple update-rc.d packages

autotools class

Autotools is one of the most commonly seen configuration methods for applications. Anything that uses the standard ./configure; make; make install sequence is using autotools. Usually the configure script will support a large number of options to specify various installation directories, to disable and/or enable various features and options to specify search paths for headers and libraries.

The autotools class takes care of all of the details for you. It defines appropriate tasks for configure, compile, stage and install. At it's simplest adding an inherit for the autotools class is all that is required. The netcat recipe for example is:

MAINTAINER = "Your name "
SECTION = "console/networking"
PR = "r1"

SRC_URI = "${SOURCEFORGE_MIRROR}/netcat/netcat-${PV}.tar.bz2"

inherit autotools

The header is defined, the location of the source code and then the inherit. For the simplest cases this is all that is required. If you need to pass additional parameters to the configure script, such as for enabling and/or disabling options, then they can be specified via the EXTRA_OECONF variable. This example from the lftp recipe shows several extra options being passed to the configure script:

EXTRA_OECONF = "--disable-largefile --disable-rpath --with-included-readline=no"

If you define your own tasks for configure, compile, stage or install (via do_) then they will override the methods generated by the autotools class. If you need to perform additional operations (rather than replacing the generated operations) you can use the do__append or do__prepend methods. The following example from the conserver recipe shows some additional items being installed:

# Include the init script and default settings in the package
do_install_append () {
    install -m 0755 -d ${D}${sysconfdir}/default ${D}${sysconfdir}/init.d
    install -m 0644 ${WORKDIR}/conserver.default ${D}${sysconfdir}/default/conserver
    install -m 0755 ${WORKDIR}/conserver.init ${D}${sysconfdir}/init.d/conserver

oe_runconf / autotools_do_configure

Autotools generates a configuration method called oe_runconf which runs the actual configure script, and a method called autotools_do_configure which generates the configure file (runs automake and autoconf) and then calls oe_runconf. The generated method for the configure task, do_configure, just calls the autotools_do_configure method.

It is sometimes desirable to implement your own do_configure method, where additional configuration is required or where you wish to inhibit the running of automake and autoconf, and then manually call oe_runconf.

The following example from the ipacct recipe shows an example of avoiding the use of automake/autoconf:

do_configure() {

Sometimes manual manipulations of the autotools files is required prior to calling autoconf/automake. In this case you can defined your own do_configure method which performs the required actions and then calls autotools_do_configure.

Presetting autoconf variables (the site file)

The autotools configuration method has support for caching the results of tests. In the cross-compilation case it is sometimes necessary to prime the cache with per-calculated results (since tests designed to run on the target cannot be run when cross-compiling). These are defined via the site file(s) for the architecture you are using and may be specific to the package you are building.

Autoconf uses site files as definied in the CONFIG_SITE variable, which is a space seperate list of files to load in the specified order. Details on how this variable is set is provided in the siteinfo class (the class responsbile for setting the variable) section.

There are some things that you should keep in mind about the caching of configure tests:

  1. Check the other site files to see if there any entries for the application you are attempting to build.

    Sometimes entries are only updated for the target that the developer has access to. If they exist for another target then it may provide a good idea of what needs to be defined.

  2. Sometimes the same cache value is used by multiple applications.

    This can have the side effect where a value added for one application breaks the build of another. It is a very good idea to empty the site file of all other values if you are having build problems to ensure that none of the existing values are causing problems.

  3. Not all values can be stored in the cache

    Caching of variables is defined by the author of the configure script, so sometimes not all variables can be set via the cache. In this case it often means resorting to patching the original configure scripts to achieve the desired result.

All site files are shell scripts which are run by autoconf and therefore the syntax is the same as you would use in sh. There are two current methods of settings variables that is used in the existing site files. This include explicitly settings the value of the variable:


and conditionally setting the value of the variable:


The conditional version is using shell syntax to say "only set this to the specified value if it is not currently set". The conditional version allows the variable to be set in the shell prior to calling configure and it will then not be replaced by the value from the site file.


Site files are applied in order, so the application specific site files will be applied prior to the top level site file entries. The use of conditional assignment means that the first definition found will apply, while when not using conditionals the last definition found will apply.

It is possible to disable the use of the cached values from the site file by clearing the definition of CONFIG_SITE prior to running the configure script. Doing this will disable the use of the site file entirely. This however should be used as a last resort. The following example from the db recipe shows an example of this:

# Cancel the site stuff - it's set for db3 and destroys the
# configure.
do_configure() {