The build/tmp/work directory is organized by architecture. For example, when working with the machine qemuarm, we have the following four directories:

• all-poky-linux
• armv5te-poky-linux-gnueabi
• qemuarm-poky-linux-gnueabi
• x86_64-linux

The directories found here and their contents are architecture and machine dependent. We shouldn't take this as a final list, only as an illustration. The x86_64-linux directory is used to build the host sysroot content, which is detailed in the next section. The all-poky-linux directory holds the working build directories for the packages that are architecture agnostic. This fragmented structure is necessary to allow the building of multiple machines and architectures within one build directory, without conflicting with each other.

The target machine we use is qemuarm. This machine is an emulation of the ARM Versatile Platform Baseboard with the ARM926EJ-S CPU emulation that supports the ARMv5TE instructions. Poky treats qemuarm as a type of ARMv5TE because some hardware features may not be available on one device or another, even when they are supported by the CPU. Machine-specific recipes are built in the machine directory (qemuarm-poky-linux-gnueabi in this case) while the architecture-specific packages are built in the architecture-specific directory (armv5te-poky-linux-gnueabi in this case).

The build/tmp/work directory is very useful when checking for misbehavior or building failures. Its contents are stored in sub-directories following this pattern:

 <arch>/<recipe name>/<software version>

Some of the directories under this tree are:

• <sources>: This is an extracted source code of the software to be built. This directory is pointed to the WORKDIR variable.
• image: This contains the files installed by the recipe (pointed to D variable).
• packages: The extracted contents of packages are stored here.
• packages-split: The contents of packages, extracted and split, are stored here. This has a sub-directory for each package.
• temp: This stores BitBake's task code and execution logs.

The most commonly checked sub-directories are under the sysroot directory, which provides the artifacts used during cross-compilation as compilers, utilities, and libraries for the host and target; they are also checked under the build/tmp/work directory, which holds the working build directory. These directories provide valuable information for debugging.

The structure of the work directory is the same for all architectures. For every recipe, a directory with the recipe name is created. Taking the machine-specific work directory and using the sysvinit-inittab recipe as an example, we see the following:

The sysvinit-inittab recipe is a good example, which even without a machine-specific object code is a machine-specific one. It contains the inittab file that defines, among other things, the serial console devices to spawn the login process, and this varies from machine to machine as the UART device depends on the machine schematic layout.

The work directory is very useful for debugging purposes; we cover this in Chapter 9, Debugging with the Yocto Project.