Chapter7 Using bitbake and OpenEmbedded

Table of Contents

Work space
work directory (tmp/work)
Working with a single recipe
Interactive bitbake
devshell via inherit
devshell addon
Working in the devshell
Patching and patch management


If your reading this manual you probably already have some idea of what OpenEmbedded is all about, which is taking a lot of software and creating something that you can run on another device. This involves downloading some source code, compiling it, creating packages (like .deb or .rpm) and/or creating boot images that can written to flash on the device. The difficulties of cross-compiling and the variety of devices which can be supported lead to a lot more complexity in an OpenEmbedded based distribution than you'd find in a typical desktop distribution (which cross-compiling isn't needed).

A major part of OpenEmbedded deals with compiling source code for various projects. For each project this generally requires the same basic set of tasks:

  1. Download the source code, and any supporting files (such as initscripts);

  2. Extract the source code and apply any patches that might be wanted;

  3. Configure the software if needed (such as is done by running the configure script);

  4. Compile everything;

  5. Package up all the files into some package format, like .deb or .rpm or .ipk, ready for installation.

There's nothing particular unusual about this process when building on the machine the package is to be installed on. What makes this difficult is:

  1. Cross-compiling: cross-compiling is difficult, and lots of software has no support for cross-compiling - all packages included in OE are cross-compiled;

  2. Target and host are different: This means you can't compile up a program and then run it - it's compiled to run on the target system, not on the system compiling it. Lots of software tries to build and run little helper and/or test applications and this won't work when cross-compiling.

  3. Tool chains (compiler, linker etc) are often difficult to compile. Cross tool chains are even more difficult. Typically you'd go out and download a tool chain made by someone else - but not when your using OE. In OE the entire toolchain is built as part of the process. This may make things take longer initially and may make it more difficult to get started but makes it easier to apply patches and test out changes to the tool chain.

Of course there's a lot more to OE then just compiling packages though. Some of the features that OE supports includes:

  • Support for both glibc and uclibc;

  • Support for building for multiple target devices from the one code base;

  • Automatically building anything that is required for the package to compile and/or run (build and run time dependencies);

  • Creation of flash and disk images of any one of a number of types (jffs2, ext2.gz, squashfs etc) for booting directly on the target device;

  • Support for various packaging formats;

  • Automatic building all of the cross-compiling tools you'll need;

  • Support for "native" packages that are built for the host computer and not for the target and used to help during the build process;

The rest of this chapter assumes you have mastered the Getting Start guides to OpenEmbedded (see the OpenEmbedded web site for details), and therefore have an appropriately configured setup and that you have managed to actually build the cross-compilers for your target. This section talks you through some of the background on what is happening with the aim of helping you understand how to debug and develop within OpenEmbedded.

You'll also not a lot of reference to variables that define specific directories or change the behaviour of some part of the build process. You should refer to Recipes chapter for full details on these variables.