SDK

Cross Development SDK

The most common way is to cross compile rather than compiling natively. Yocto provides an SDK package that can be built for an image to match possible dependencies in the image.

Building the SDK

run this command to generate a cross development SDK:

bitbake <image name> -c populate_sdk
# for example:
bitbake ost-image -c populate_sdk

This will generate a toolchain with a sysroot containing all header/libraries/… included in the image. By default the SDK is in build/tmp/deploy/sdk/.

Changing the SDK HOST CPU Architecture

By default, the SDK is built for x86_64 host machines. That means you can use the SDK on x86_64 computers to build software for the target. If you want to use the SDK on another system such as the ARM based Apple Macbooks, the SDK host architecture needs to be specified accordingly. This is achieved through the SDKMACHINE variable. To build the SDK for a 64bit ARM host (e.g. ARM based Apple computers), add the following to local.conf:

SDKMACHINE = "aarch64"

Installing the SDK

The sdk can be built as described above or can be fetched from Linux Images. It does do not need to be extracted any further. Building the SDK will generate a few files. The most important one being a .sh script that is used to install the SDK. For example, building the SDK yields:

poky-glibc-x86_64-ost-image-dev-armv7at2hf-neon-bblue-toolchain-3.0.2.host.manifest
poky-glibc-x86_64-ost-image-dev-armv7at2hf-neon-bblue-toolchain-3.0.2.sh
poky-glibc-x86_64-ost-image-dev-armv7at2hf-neon-bblue-toolchain-3.0.2.target.manifest
poky-glibc-x86_64-ost-image-dev-armv7at2hf-neon-bblue-toolchain-3.0.2.testdata.json

Note that the file names include information about the image and hardware it was built for.

Installing the SDK is as simple as executing the shell script (e.g. poky-glibc-x86_64-ntb-dev-image-armv7at2hf-neon-bblue-toolchain-3.0.2.sh) and following the instructions. An example installation is shown below.

./tmp/deploy/sdk/poky-glibc-x86_64-ost-image-dev-armv7at2hf-neon-bblue-toolchain-3.0.2.sh
Poky (Yocto Project Reference Distro) SDK installer version 3.0.2
=================================================================
Enter target directory for SDK (default: /opt/poky/3.0.2):
You are about to install the SDK to "/opt/poky/3.0.2". Proceed [Y/n]? y
Extracting SDK.......................................................................................done
Setting it up...done
SDK has been successfully set up and is ready to be used.
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
 $ . /opt/poky/3.0.2/environment-setup-armv7at2hf-neon-poky-linux-gnueabi

There are two things of note: The script will ask for a location to install the SDK to in case you do not want to install it to its default location. Also the last line of output will tell you what script needs to be sourced in order to use the SDK (see below).

Using the SDK

The SDK includes a script that needs to be sourced in order to use the SDK. This, among other things, sets up the standard environment variables (such as CC, LD and CFLAGS).

The script is located in the SDK install directory and the install script tells you where to find it.

For the example above, the command is:

. /opt/poky/3.0.2/environment-setup-armv7at2hf-neon-poky-linux-gnueabi

Note the space between . and the path. The script needs to be sourced rather than executed. Now running any standard build system (eg make) should pick up the cross compile settings and automatically build for the target platform.

Developing Kernel Modules

When using meta-ost, the SDK contains the kernel dev sources by default. However, properly compiling an out of tree module requires some additional steps:

. path/to/sdk/environment-setup-aarch64-linux-<arch>
pushd path/to/sdk/sysroot/<arch>/usr/src/kernel
make scripts
make prepare

Source: how-to-build-linux-kernel-module-using-yocto-sdk

Note that depending on the location of the installed SDK, make scripts may encounter permission errors. This has been observed when installing the SDK in /opt. The easiest way to work around this is installing the SDK in a location under the current user's home directory.

Additional Information