%poky; ] >

You can use existing, pre-built toolchains by locating and running an SDK installer script that ships with the Yocto Project. Using this method, you select and download an architecture-specific toolchain installer and then run the script to hand-install the toolchain. You can find SDK installers here: Standard SDK Installers Go to and find the folder that matches your host development system (i.e. i686 for 32-bit machines or x86_64 for 64-bit machines). Go into that folder and download the toolchain installer whose name includes the appropriate target architecture. The toolchains provided by the Yocto Project are based off of the core-image-sato image and contain libraries appropriate for developing against that image. For example, if your host development system is a 64-bit x86 system and you are going to use your cross-toolchain for a 32-bit x86 target, go into the x86_64 folder and download the following installer: poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh Extensible SDK Installers Installers for the extensible SDK are in .

As an alternative to locating and downloading a toolchain installer, you can build the toolchain installer if you have a Build Directory. Although not the preferred method, it is also possible to use bitbake meta-toolchain to build the toolchain installer. If you do use this method, you must separately install and extract the target sysroot. For information on how to install the sysroot, see the "Extracting the Root Filesystem" section. To build the toolchain installer for a standard SDK and populate the SDK image, use the following command: $ bitbake image -c populate_sdk You can do the same for the extensible SDK using this command: $ bitbake image -c populate_sdk_ext These commands result in a toolchain installer that contains the sysroot that matches your target root filesystem. Another powerful feature is that the toolchain is completely self-contained. The binaries are linked against their own copy of libc, which results in no dependencies on the target system. To achieve this, the pointer to the dynamic loader is configured at install time since that path cannot be dynamically altered. This is the reason for a wrapper around the populate_sdk and populate_sdk_ext archives. Another feature is that only one set of cross-canadian toolchain binaries are produced per architecture. This feature takes advantage of the fact that the target hardware can be passed to gcc as a set of compiler options. Those options are set up by the environment script and contained in variables such as CC and LD. This reduces the space needed for the tools. Understand, however, that a sysroot is still needed for every target since those binaries are target-specific. Remember, before using any BitBake command, you must source the build environment setup script (i.e. &OE_INIT_FILE; or oe-init-build-env-memres) located in the Source Directory and you must make sure your conf/local.conf variables are correct. In particular, you need to be sure the MACHINE variable matches the architecture for which you are building and that the SDKMACHINE variable is correctly set if you are building a toolchain designed to run on an architecture that differs from your current development host machine (i.e. the build machine). When the bitbake command completes, the toolchain installer will be in tmp/deploy/sdk in the Build Directory. By default, this toolchain does not build static binaries. If you want to use the toolchain to build these types of libraries, you need to be sure your image has the appropriate static development libraries. Use the IMAGE_INSTALL variable inside your local.conf file to install the appropriate library packages. Following is an example using glibc static development libraries: IMAGE_INSTALL_append = " glibc-staticdev"

After installing the toolchain or building it using BitBake, you need a root filesystem, which you need to separately extract. Here are some cases where you need to extract the root filesystem: You want to boot the image using NFS. You want to use the root filesystem as the target sysroot. For example, the Eclipse IDE environment with the Eclipse Yocto Plug-in installed allows you to use QEMU to boot under NFS. You want to develop your target application using the root filesystem as the target sysroot. To extract the root filesystem, first source the cross-development environment setup script to establish necessary environment variables. If you built the toolchain in the Build Directory, you will find the toolchain environment script in the tmp directory. If you installed the toolchain by hand, the environment setup script is located in /opt/poky/&DISTRO;. After sourcing the environment script, use the runqemu-extract-sdk command and provide the filesystem image. Following is an example. The second command sets up the environment. In this case, the setup script is located in the /opt/poky/&DISTRO; directory. The third command extracts the root filesystem from a previously built filesystem that is located in the ~/Downloads directory. Furthermore, this command extracts the root filesystem into the qemux86-sato directory: $ cd ~ $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux $ runqemu-extract-sdk \ ~/Downloads/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2 \ $HOME/qemux86-sato You could now point to the target sysroot at qemux86-sato.

The following figure shows the resulting directory structure after you install the Standard SDK by running the .sh SDK installation script: The installed SDK consists of an environment setup script for the SDK, a configuration file for the target, a version file for the target, and the root filesystem (sysroots) needed to develop objects for the target system. Within the figure, italicized text is used to indicate replaceable portions of the file or directory name. For example, install_dir/version is the directory where the SDK is installed. By default, this directory is /opt/poky/. And, version represents the specific snapshot of the SDK (e.g. &DISTRO;+snapshot). Furthermore, target represents the target architecture (e.g. i586) and host represents the development system's architecture (e.g. x86_64). Thus, the complete names of the two directories within the sysroots could be i586-poky-linux and x86_64-pokysdk-linux for the target and host, respectively.

The following figure shows the resulting directory structure after you install the Extensible SDK by running the .sh SDK installation script: The installed directory structure for the extensible SDK is quite different than the installed structure for the standard SDK. The extensible SDK does not separate host and target parts in the same manner as does the standard SDK. The extensible SDK uses an embedded copy of the build system, which has its own sysroots. Of note in the directory structure are an environment setup script for the SDK, a configuration file for the target, a version file for the target, and a log file for the build system preparation script run by the installer. Within the figure, italicized text is used to indicate replaceable portions of the file or directory name. For example, install_dir is the directory where the SDK is installed, which is poky_sdk by default. target represents the target architecture (e.g. i586) and host represents the development system's architecture (e.g. x86_64).