Next, observe the changes necessary for local.conf in order to use a specific overlay (in this case org.openmoko.dev).

<pre>

<pre>

Line 272:

Line 277:

BBFILES += " ${OE_HOME}/org.openmoko.dev/packages/*/*.bb"

BBFILES += " ${OE_HOME}/org.openmoko.dev/packages/*/*.bb"

−

BBFILE_COLLECTIONS = "upstream local"

+

BBFILE_COLLECTIONS = "upstream moko"

BBFILE_PATTERN_upstream = "${OE_HOME}/org.openembedded.dev"

BBFILE_PATTERN_upstream = "${OE_HOME}/org.openembedded.dev"

BBFILE_PRIORITY_upstream = "0"

BBFILE_PRIORITY_upstream = "0"

−

BBFILE_PATTERN_local = "${OE_HOME}/org.openmoko.dev"

+

BBFILE_PATTERN_moko = "${OE_HOME}/org.openmoko.dev"

−

BBFILE_PRIORITY_local = "1"

+

BBFILE_PRIORITY_moko = "1"

...

...

</pre>

</pre>

−

In order for the overlay to be detected by BitBake, the above variables need to be defined. It is possible to have more than one overlay and each one should be given a different priority.

+

In order for the overlay to be detected by BitBake, the above variables need to be defined in the local.conf file. It is possible to include more than one overlay. For each overlay, add a separate BBFILES += statement, an entry in BBFILE_COLLECTIONS, a BBFILE_PATTERN, and BBFILE_PRIORITY. Remember to include at least one space (' ') between each BBFILES entry.

Building the OpenMoko Distribution with OpenEmbedded

Note: If you are an application developer, you probably do not want to build OpenEmbedded from scratch. For compiling simple applications with few library dependencies (including boot-loader and kernel), consider using our prebuilt Toolchain. For more complex applications with many library dependencies, download a prebuilt OpenEmbedded Torrent.

Building OpenMoko from scratch is a time-, cpu- and diskspace-consuming process which should only be done if you are a system integrator and want to customize your OpenMoko distribution.

Simplified Instructions: MokoMakefile

For beginners who wish to customize their OpenMoko distribution, the facility called MokoMakefile simplifies building OpenEmbedded.

Quick Start: OpenEmbedded Torrent

If you are a system developer and would like to get up-to-speed as quickly as possible, then download an OpenEmbedded Torrent.

From Scratch: OpenEmbedded

Beginner OpenMoko developers who would prefer to have full control over their OpenEmbedded build environment should follow the instructions below.

Preparations

Several prerequisite software components are necessary in order to have a fully functional OpenEmbedded build environment. However, setup and installation varies depending on the operating system installed on your workstation. The OpenEmbedded Wiki provides setup instructions for FreeBSD, Mac OS X, and most major Linux distributions, of course.

${OE_HOME}

Assuming that you have installed all prerequisite software, you are now ready to create a directory for all of your OpenEmbedded (OE) related work. We will refer to OE_HOME in a generic way, but for argument's sake, assume that it is equal to ${HOME}/oe. You should expect ${OE_HOME} to grow tremendously in size, up to approximately 8GB or larger in some cases. Also be aware, that a full OE build could require several hours of constant building, which may inhibit the performance of your computer while performing other tasks. Replace ${HOME}/oe with your preferred location.

For Bash users:

export OE_HOME=${HOME}/oe

For Tcsh users:

setenv OE_HOME ${HOME}/oe

Next, run 'mkdir -p ${OE_HOME}' to create the directory.

Synchronizing OpenEmbedded With Git

Just like any tree, OpenEmbedded has several branches. In this case they are called 'development branches'. Some noteworthy ones include org.openembedded.dev (the default) and org.openembedded.stable .

Note that last argument could be any directory name (git will create the directory if it doesn't exist). Sticking to 'good convention', the directory name was chosen to reflect the default development branch, org.openembedded.dev . See the OE GitPhraseBook for more info on checking out different branches.

Also, please explore the directory structure of the OpenEmbedded build tree. Take a few moments to inspect the different types of BitBake files (.bbclass, .bb, .inc, etc). This helps one to become familiar with recipe syntax and the inheritance system. Of particular note, please read the file 'local.conf.sample'.

local.conf

If you explored local.conf.example, then you would be aware that there are some very important variables to be set like MACHINE, DISTRO, and BBFILES, among many others. This is done in a configuration file (local.conf) inside the build directory.

Note: Using BitBake and OE for cross-compilation require that each target-distro combination is built in a separate directory, so that no version collisions occur. Concurrent builds may safely share the same DL_DIR though. This would suggest that a safe name for build directories is of the form ${OE_HOME}/build-${MACHINE}-${DISTRO}. Of course, if you don't plan on building for more than one machine-distro combination, then the naming of this directory is arbitrary. For the purpose of this example, we will use the convention ${OE_HOME}/build-${MACHINE} .

Now, create the 'local.conf' configuration file. Notice that the CACHE and TMPDIR variables are neatly kept within the build directory while the DL_DIR variable is outside of the build directory, so that concurrent builds may reuse the same source packages.

The BBFILES variable is also of prime importance! It tells bitbake where to locate all available recipes for a build. The OpenEmbedded build environment is almost completely ready to go, with just one more minor step left.

setup-env

For quick and easy initialization of the OpenEmbedded build environment, it is often suggested that the developer create a 'setup-env' script to source from the command line. This script can be called to initialize the most important of environment variables. Below is a very basic example of a setup-env script.

To invoke the setup-env script in bash, run 'source setup-env'. In tcsh, run '. setup-env'.

See the section entitled BitBake Overlays for an example of a more complicated setup-env script.

Testing the OE Build Environment

That's it! Now you should be prepared to bake your first BitBake recipe.

bitbake helloworld

Building an Image

There are several full filesystem images which can be built directly with OpenEmbedded using a single command. These include openmoko-image, fso-image, and so on. The image definitions can be found under ${OE_HOME}/org.openembedded.dev/packages/images

A good place to start is with

bitbake fso-image

That concludes this introduction to BitBake and OpenEmbedded. Good luck!

Other References

Broken Builds and Bug Reporting

Using the org.openembedded.dev branch can often result in broken builds. For that reason, it is usually a good idea to limit synchronizing with the repository only after successfully building an image. Some may even want to archive the tree and build directory after an image is built.

Now in the case that an image does not successfully build, it is not always necessarily a bug or a new bug. The problem might have to do with some conflicting software on the workstation, and it could be a bug that is already know and being fixed.

Below are a few useful steps to follow when a build does not successfully complete:

Identify the package that failed to build

Find a line near the bottom of your output that matches "ERROR: ... failed" or "NOTE: ... failed". The name of the package should be contained in the '...'

If there is a similar, more stable version in ${OE_HOME}/org.openembedded.dev/packages, then try to use that instead

Find the log file. There should be a line near the bottom of your output that matches "ERROR: see log in ...", where '...' contains the log file name. These are usually of the form log.do_compile.12345 or log.do_configure.12345, etc.

Try to identify the root cause of the error

In many cases, if one examines log.do_configure, only the error is reported, but not the cause of the error

Most packages that build with autotools will also have a config.log file that contains the exact cause of the error

If you can fix the error, and the error is local to your workstation, and not really a bug, then fix the error yourself.

Where to Report Bugs

Tips & Tricks

Setting the PREFERRED_VERSION for a package

If a certain package is known to not build, and there is a less recent / more stable version of that package, then a good way to avoid repetitive encounters with known build failures is to use preferred versions of packages.

For example, if building gcc-4.2.4 constantly failed, then it would be wise to edit local.conf and set PREFERRED_VERSION_gcc = "4.1.2".

Screen is Your Friend

If you happen to be building all of your packages remotely on a server, using an ssh session, the session might occasionally be interrupted and the connection could be terminated. A similar event could occur if your X server suddenly craches. If in the process of building an image with bitbake, this means that the build process will terminate as well.

In order to ensure that a build continues in the presence of communication failures, it is advisable to use the GNU Screen utility. Screen is also very useful when performing several concurrent OpenEmbedded builds for different machine-distro combinations.

Screen installation varies with your OS and distribution.

BitBake Overlays

Bitbake overlays are useful for OpenEmbedded developers to eliminate bugs or package software without disturbiing the OpenEmbedded tree itself. Overlays are very similar in structure to the OpenEmbedded tree, but are usually only sparsely populated. Non-sparsely poplulated overlays are actually more closely related to separate development branches. Good convention would suggest to always name the overlay appropriately.

Below is an example of two overlays, three build directories, a setup-env script, and a local.conf where the developer has multiple build targets as well as multiple BitBake overlays.

In order for the overlay to be detected by BitBake, the above variables need to be defined in the local.conf file. It is possible to include more than one overlay. For each overlay, add a separate BBFILES += statement, an entry in BBFILE_COLLECTIONS, a BBFILE_PATTERN, and BBFILE_PRIORITY. Remember to include at least one space (' ') between each BBFILES entry.

Useful BitBake Commands

# list all of the tasks defined for a given package_name
bitbake -c listtasks <package_name>
# clean the work directory for a specific package
bitbake -c clean <package_name>
# build a specific recipe
bitbake -b <path/to/some/recipe.bb>

Building the OpenMoko Distribution with OpenEmbedded

Note: If you are an application developer, you probably do not want to build OpenEmbedded from scratch. For compiling simple applications with few library dependencies (including boot-loader and kernel), consider using our prebuilt Toolchain. For more complex applications with many library dependencies, download a prebuilt OpenEmbedded Torrent.

Building OpenMoko from scratch is a time-, cpu- and diskspace-consuming process which should only be done if you are a system integrator and want to customize your OpenMoko distribution.

Simplified Instructions: MokoMakefile

For beginners who wish to customize their OpenMoko distribution, the facility called MokoMakefile simplifies building OpenEmbedded.

Quick Start: OpenEmbedded Torrent

If you are a system developer and would like to get up-to-speed as quickly as possible, then download an OpenEmbedded Torrent.

From Scratch: OpenEmbedded

Beginner OpenMoko developers who would prefer to have full control over their OpenEmbedded build environment should follow the instructions below.

Preparations

Several prerequisite software components are necessary in order to have a fully functional OpenEmbedded build environment. However, setup and installation varies depending on the operating system installed on your workstation. The OpenEmbedded Wiki provides setup instructions for FreeBSD, Mac OS X, and most major Linux distributions, of course.

${OE_HOME}

Assuming that you have installed all prerequisite software, you are now ready to create a directory for all of your OpenEmbedded (OE) related work. We will refer to OE_HOME in a generic way, but for argument's sake, assume that it is equal to ${HOME}/oe. You should expect ${OE_HOME} to grow tremendously in size, up to approximately 8GB or larger in some cases. Also be aware, that a full OE build could require several hours of constant building, which may inhibit the performance of your computer while performing other tasks. Replace ${HOME}/oe with your preferred location.

For Bash users:

export OE_HOME=${HOME}/oe

For Tcsh users:

setenv OE_HOME ${HOME}/oe

Next, run 'mkdir -p ${OE_HOME}' to create the directory.

Synchronizing OpenEmbedded With Git

Just like any tree, OpenEmbedded has several branches. In this case they are called 'development branches'. Some noteworthy ones include org.openembedded.dev (the default) and org.openembedded.stable .

Note that last argument could be any directory name (git will create the directory if it doesn't exist). Sticking to 'good convention', the directory name was chosen to reflect the default development branch, org.openembedded.dev . See the OE GitPhraseBook for more info on checking out different branches.

Also, please explore the directory structure of the OpenEmbedded build tree. Take a few moments to inspect the different types of BitBake files (.bbclass, .bb, .inc, etc). This helps one to become familiar with recipe syntax and the inheritance system. Of particular note, please read the file 'local.conf.sample'.

local.conf

If you explored local.conf.example, then you would be aware that there are some very important variables to be set like MACHINE, DISTRO, and BBFILES, among many others. This is done in a configuration file (local.conf) inside the build directory.

Note: Using BitBake and OE for cross-compilation require that each target-distro combination is built in a separate directory, so that no version collisions occur. Concurrent builds may safely share the same DL_DIR though. This would suggest that a safe name for build directories is of the form ${OE_HOME}/build-${MACHINE}-${DISTRO}. Of course, if you don't plan on building for more than one machine-distro combination, then the naming of this directory is arbitrary. For the purpose of this example, we will use the convention ${OE_HOME}/build-${MACHINE} .

Now, create the 'local.conf' configuration file. Notice that the CACHE and TMPDIR variables are neatly kept within the build directory while the DL_DIR variable is outside of the build directory, so that concurrent builds may reuse the same source packages.

The BBFILES variable is also of prime importance! It tells bitbake where to locate all available recipes for a build. The OpenEmbedded build environment is almost completely ready to go, with just one more minor step left.

setup-env

For quick and easy initialization of the OpenEmbedded build environment, it is often suggested that the developer create a 'setup-env' script to source from the command line. This script can be called to initialize the most important of environment variables. Below is a very basic example of a setup-env script.

To invoke the setup-env script in bash, run 'source setup-env'. In tcsh, run '. setup-env'.

See the section entitled BitBake Overlays for an example of a more complicated setup-env script.

Testing the OE Build Environment

That's it! Now you should be prepared to bake your first BitBake recipe.

bitbake helloworld

Building an Image

There are several full filesystem images which can be built directly with OpenEmbedded using a single command. These include openmoko-image, fso-image, and so on. The image definitions can be found under ${OE_HOME}/org.openembedded.dev/packages/images

A good place to start is with

bitbake fso-image

That concludes this introduction to BitBake and OpenEmbedded. Good luck!

Other References

Broken Builds and Bug Reporting

Using the org.openembedded.dev branch can often result in broken builds. For that reason, it is usually a good idea to limit synchronizing with the repository only after successfully building an image. Some may even want to archive the tree and build directory after an image is built.

Now in the case that an image does not successfully build, it is not always necessarily a bug or a new bug. The problem might have to do with some conflicting software on the workstation, and it could be a bug that is already know and being fixed.

Below are a few useful steps to follow when a build does not successfully complete:

Identify the package that failed to build

Find a line near the bottom of your output that matches "ERROR: ... failed" or "NOTE: ... failed". The name of the package should be contained in the '...'

If there is a similar, more stable version in ${OE_HOME}/org.openembedded.dev/packages, then try to use that instead

Find the log file. There should be a line near the bottom of your output that matches "ERROR: see log in ...", where '...' contains the log file name. These are usually of the form log.do_compile.12345 or log.do_configure.12345, etc.

Try to identify the root cause of the error

In many cases, if one examines log.do_configure, only the error is reported, but not the cause of the error

Most packages that build with autotools will also have a config.log file that contains the exact cause of the error

If you can fix the error, and the error is local to your workstation, and not really a bug, then fix the error yourself.

Where to Report Bugs

Tips & Tricks

Setting the PREFERRED_VERSION for a package

If a certain package is known to not build, and there is a less recent / more stable version of that package, then a good way to avoid repetitive encounters with known build failures is to use preferred versions of packages.

For example, if building gcc-4.2.4 constantly failed, then it would be wise to edit local.conf and set PREFERRED_VERSION_gcc = "4.1.2".

Screen is Your Friend

If you happen to be building all of your packages remotely on a server, using an ssh session, the session might occasionally be interrupted and the connection could be terminated. A similar event could occur if your X server suddenly craches. If in the process of building an image with bitbake, this means that the build process will terminate as well.

In order to ensure that a build continues in the presence of communication failures, it is advisable to use the GNU Screen utility. Screen is also very useful when performing several concurrent OpenEmbedded builds for different machine-distro combinations.

Screen installation varies with your OS and distribution.

BitBake Overlays

Bitbake overlays are useful for OpenEmbedded developers to eliminate bugs or package software without disturbiing the OpenEmbedded tree itself. Overlays are very similar in structure to the OpenEmbedded tree, but are usually only sparsely populated. Non-sparsely poplulated overlays are actually more closely related to separate development branches. Good convention would suggest to always name the overlay appropriately.

Below is an example of two overlays, three build directories, a setup-env script, and a local.conf where the developer has multiple build targets as well as multiple BitBake overlays.

In order for the overlay to be detected by BitBake, the above variables need to be defined in the local.conf file. It is possible to include more than one overlay. For each overlay, add a separate BBFILES += statement, an entry in BBFILE_COLLECTIONS, a BBFILE_PATTERN, and BBFILE_PRIORITY. Remember to include at least one space (' ') between each BBFILES entry.

Useful BitBake Commands

# list all of the tasks defined for a given package_name
bitbake -c listtasks <package_name>
# clean the work directory for a specific package
bitbake -c clean <package_name>
# build a specific recipe
bitbake -b <path/to/some/recipe.bb>