How to build


For reference, see :

Required Packages for the Host Development System

The list of packages you need on the host development system can be large when covering all build scenarios using the Yocto Project. This section provides required packages according to Linux distribution and function.

    Ubuntu and Debian
The following list shows the required packages by function given a supported Ubuntu or Debian Linux distribution:

Essentials: Packages needed to build an image on a headless system:

     $ sudo apt-get install gawk wget git-core diffstat unzip texinfo \
     build-essential chrpath
Graphical Extras: Packages recommended if the host system has graphics support:

     $ sudo apt-get install libsdl1.2-dev xterm
Documentation: Packages needed if you are going to build out the Yocto Project documentation manuals:

     $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto
ADT Installer Extras: Packages needed if you are going to be using the Application Development Toolkit (ADT) Installer:

     $ sudo apt-get install autoconf automake libtool libglib2.0-dev

Initial setup

   1 mkdir openembedded
   2 cd openembedded
   3 git clone git://
   4 cd jenkins-setup
   5 sudo bash
   6 bash

This will clone all the required repositories and do the initial setup.

Do a build

   1 cd openembedded-core
   2 source oe-init-build-env ../build
   3 bitbake bash

Of course you can use other targets instead of "bash". Use "core-image-minimal" to build a simple rootfs.

Usable build targets

  • linaro-image-minimal - very minimal rootfs
  • linaro-image-lamp - LAMP stack + toolchain
  • meta-toolchain - binary toolchain which can be installed separately

If you want to boot images directly, instead of feeding the rootfs to linaro-media-create, you need to add ext3 to IMAGE_FSTYPES to your conf/site.conf. If you want extra space, set IMAGE_ROOTFS_EXTRA_SPACE.

IMAGE_FSTYPES="tar.gz ext3"
IMAGE_ROOTFS_EXTRA_SPACE="1000000" # 1GB of free space to image

World build

If you want to check what builds and what doesn't then "bitbake world -k" would be best. This will do a build of every recipe possible and will not stop on the first failure (due to "-k" argument).

Possible config changes

By default your build will remove sources after successful compilation. This can be changed by removing/commenting one line in build/conf/site.conf file:

INHERIT += "rm_work"

Build flags are set in and genericarmv8.conf (both present in conf/machine area of meta-aarch64 layer).

External toolchain support

Instead of making own cross toolchain during build we can use one of those provided by Linaro. Required steps:

  1. fetch cross toolchain from page

  2. unpack it somewhere - let assume /opt/linaro/gcc-armv8/ for now
  3. Edit conf/site.conf file and add:

# cross toolchain from tcwg
TCMODE = "external-linaro"
ELT_TARGET_SYS = "aarch64-linux-gnu"
EXTERNAL_TOOLCHAIN = "/opt/linaro/gcc-armv8/"

For ARMv7a cross toolchain drop ELT_TARGET_SYS variable.

Now you can do a build.

Running images

How to setup the system and run an image in the fast model is described in

Handling build failures

We can split build failures into various types. Let's look at them one by one.

gnu-config update required

For software using autotools OpenEmbedded by default runs "autoreconf" to regenerate configure scripts and also takes care of updating gnu-config files (config.{sub,guess}). But some recipes ship with their own "do_configure()" task definition...

What to do in such case? The easiest method is to add "gnu-configize --force" call at the start of the "do_configure()" task. This will take care of the update.

For some recipes it does not work because gnu-config files are in a subdirectory. In such cases I suggest this piece of code:

do_configure_prepend() {
       install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess ${S}/subdir/
       install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub ${S}/subdir/

${S} is directory with sources.

porting required

Some software will require porting to the AArch64 architecture. If you have a patch which does it then I suggest the following order:

  1. "bitbake softwarename -c patch" - this will unpack and apply OE patches
  2. "bitbake softwarename -c devshell" - this will give you an xterm or screen session inside ${S} of the unpacked/patched softwarename sources
  3. use quilt to apply your patch
  4. create "bbappend" for softwarename - a good example is meta-aarch64/recipes-core/eglibc/eglibc_2.16.bbappend
  5. build: "bitbake softwarename"
  6. git commit && git push

You can also patch the upstream recipe and send them a patch with "git send-email". But first read README in the repository because "meta-oe" layer requires you to format 'Subject:' properly.

The other option is to send a patch to hrw or suihkulokki for integration.

extra build dependencies not yet available for AArch64

Some recipes have build dependencies not yet available for the AArch64 architecture. For example "ltp" in OE requires "libaio" which we lack. So remove the dependency from the DEPENDS variable and check if it builds. If it does and the result is ok then again - create "bbappend" (ltp is good example) or contact us to get it done.

altering images

adding more packages into image

Simplest option is to use:

CORE_IMAGE_EXTRA_INSTALL += "package1 package2 package3"

in conf/local.conf - this works for local builds just fine.

If you want those changes to be permanent please open bug on

adding extra files into image

There are a couple of options for it.

simple one

Build image, mount resulting ext2 image file, add your data, umount, boot model.

automated one

Use meta-linaro/recipes-linaro/files-injection/ recipe. Instructions are inside.

HowTo/ARMv8/OpenEmbedded (last modified 2017-04-07 17:07:17)