%poky; ] > This chapter describes the standard SDK and how to use it. Information covers the pieces of the SDK, how to install it, and presents several task-based procedures common for developing with a standard SDK. The tasks you can perform using a standard SDK are also applicable when you are using an extensible SDK. For information on the differences when using an extensible SDK as compared to an extensible SDK, see the "Using the Extensible SDK" chapter.

Fundamentally, the standard SDK exists so that you can access cross-development tools. This paragraph describes why you use the Standard SDK. Probably need to compare that against why you would not be interested in the extensible SDK here as well. According to Paul, the most interest lies in the extensible SDK. So providing this comparison would be helpful. Currently, my understanding boils down to this: The only reason to use the Standard SDK is if you want to build and debug source code that you have. That pretty much sums it up. If there is more detail, I need to know about it. The installed Standard SDK consists of several files and directories. Basically, it contains an SDK environment setup script, some configuration files, and host and target root filesystems to support usage. You can see the directory structure in the "Installed Standard SDK Directory Structure" section. You can also find information on how the Yocto Project OpenEmbedded build system creates an SDK image by looking at the "SDK Generation" section in the Yocto Project Reference Manual.

The first thing you need to do is install the SDK on your host development machine by running the .sh installation script. You can download a tarball installer, which includes the pre-built toolchain, the runqemu script, and support files from the appropriate directory under . Toolchains are available for 32-bit and 64-bit x86 development systems from the i686 and x86_64 directories, respectively. The toolchains the Yocto Project provides are based off the core-image-sato image and contain libraries appropriate for developing against that image. Each type of development system supports five or more target architectures. The names of the tarball installer scripts are such that a string representing the host system appears first in the filename and then is immediately followed by a string representing the target architecture. poky-glibc-host_system-image_type-arch-toolchain-release_version.sh Where: host_system is a string representing your development system: i686 or x86_64. image_type is a string representing the image you wish to develop a SDK for use against. The Yocto Project builds installers for standard SDKs using the following BitBake command: bitbake core-image-sato -c populate_sdk arch is a string representing the tuned target architecture: i586, x86_64, powerpc, mips, armv7a or armv5te release_version is a string representing the release number of the Yocto Project: &DISTRO;, &DISTRO;+snapshot For example, the following toolchain installer is for a 64-bit development host system and a i586-tuned target architecture based off the SDK for core-image-sato and using the current &DISTRO; snapshot: poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh The SDK and toolchains are self-contained and by default are installed into /opt/poky. However, when you run the SDK installer, you can choose an installation directory. You must change the permissions on the toolchain installer script so that it is executable. The following command shows how to run the installer given a toolchain tarball for a 64-bit x86 development host system and a 32-bit x86 target architecture. The example assumes the toolchain installer is located in ~/Downloads/. If you do not have write permissions for the directory into which you are installing the SDK, the installer notifies you and exits. Be sure you have write permissions in the directory and run the installer again. $ ./poky-glibc-x86_64-core-image-sato-i586-toolchain-2.1.sh Poky (Yocto Project Reference Distro) SDK installer version 2.0 =============================================================== Enter target directory for SDK (default: /opt/poky/2.1): You are about to install the SDK to "/opt/poky/2.1". 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/2.1/environment-setup-i586-poky-linux Again, reference the "Installed Standard SDK Directory Structure" section for more details on the resulting directory structure of the installed SDK.

Once you have the SDK installed, you must run the SDK environment setup script before you can actually use it. This setup script resides in the directory you chose when you installed the SDK. For information on where this setup script can reside, see the "Obtaining the SDK" Appendix. Before running the script, be sure it is the one that matches the architecture for which you are developing. Environment setup scripts begin with the string "environment-setup" and include as part of their name the tuned target architecture. For example, the command to source a setup script for an IA-based target machine using i586 tuning and located in the default SDK installation directory is as follows: $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux When you run the setup script, many environment variables are defined: SDKTARGETSYSROOT - The path to the sysroot used for cross-compilation PKG_CONFIG_PATH - The path to the target pkg-config files CONFIG_SITE - A GNU autoconf site file preconfigured for the target CC - The minimal command and arguments to run the C compiler CXX - The minimal command and arguments to run the C++ compiler CPP - The minimal command and arguments to run the C preprocessor AS - The minimal command and arguments to run the assembler LD - The minimal command and arguments to run the linker GDB - The minimal command and arguments to run the GNU Debugger STRIP - The minimal command and arguments to run 'strip', which strips symbols RANLIB - The minimal command and arguments to run 'ranlib' OBJCOPY - The minimal command and arguments to run 'objcopy' OBJDUMP - The minimal command and arguments to run 'objdump' AR - The minimal command and arguments to run 'ar' NM - The minimal command and arguments to run 'nm' TARGET_PREFIX - The toolchain binary prefix for the target tools CROSS_COMPILE - The toolchain binary prefix for the target tools CONFIGURE_FLAGS - The minimal arguments for GNU configure CFLAGS - Suggested C flags CXXFLAGS - Suggested C++ flags LDFLAGS - Suggested linker flags when you use CC to link CPPFLAGS - Suggested preprocessor flags

Once you have a suitable cross-toolchain installed, it is very easy to develop a project outside of the OpenEmbedded build system. This section presents a simple "Helloworld" example that shows how to set up, compile, and run the project.

Follow these steps to create a simple Autotools-based project: Create your directory: Create a clean directory for your project and then make that directory your working location: $ mkdir $HOME/helloworld $ cd $HOME/helloworld Populate the directory: Create hello.c, Makefile.am, and configure.in files as follows: For hello.c, include these lines: #include <stdio.h> main() { printf("Hello World!\n"); } For Makefile.am, include these lines: bin_PROGRAMS = hello hello_SOURCES = hello.c For configure.in, include these lines: AC_INIT(hello.c) AM_INIT_AUTOMAKE(hello,0.1) AC_PROG_CC AC_PROG_INSTALL AC_OUTPUT(Makefile) Source the cross-toolchain environment setup file: Installation of the cross-toolchain creates a cross-toolchain environment setup script in the directory that the ADT was installed. Before you can use the tools to develop your project, you must source this setup script. The script begins with the string "environment-setup" and contains the machine architecture, which is followed by the string "poky-linux". Here is an example that sources a script from the default ADT installation directory that uses the 32-bit Intel x86 Architecture and the &DISTRO_NAME; Yocto Project release: $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux Generate the local aclocal.m4 files and create the configure script: The following GNU Autotools generate the local aclocal.m4 files and create the configure script: $ aclocal $ autoconf Generate files needed by GNU coding standards: GNU coding standards require certain files in order for the project to be compliant. This command creates those files: $ touch NEWS README AUTHORS ChangeLog Generate the configure file: This command generates the configure: $ automake -a Cross-compile the project: This command compiles the project using the cross-compiler. The CONFIGURE_FLAGS environment variable provides the minimal arguments for GNU configure: $ ./configure ${CONFIGURE_FLAGS} Make and install the project: These two commands generate and install the project into the destination directory: $ make $ make install DESTDIR=./tmp Verify the installation: This command is a simple way to verify the installation of your project. Running the command prints the architecture on which the binary file can run. This architecture should be the same architecture that the installed cross-toolchain supports. $ file ./tmp/usr/local/bin/hello Execute your project: To execute the project in the shell, simply enter the name. You could also copy the binary to the actual target hardware and run the project there as well: $ ./hello As expected, the project displays the "Hello World!" message.

For an Autotools-based project, you can use the cross-toolchain by just passing the appropriate host option to configure.sh. The host option you use is derived from the name of the environment setup script found in the directory in which you installed the cross-toolchain. For example, the host option for an ARM-based target that uses the GNU EABI is armv5te-poky-linux-gnueabi. You will notice that the name of the script is environment-setup-armv5te-poky-linux-gnueabi. Thus, the following command works to update your project and rebuild it using the appropriate cross-toolchain tools: $ ./configure --host=armv5te-poky-linux-gnueabi \ --with-libtool-sysroot=sysroot_dir If the configure script results in problems recognizing the --with-libtool-sysroot=sysroot-dir option, regenerate the script to enable the support by doing the following and then run the script again: $ libtoolize --automake $ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \ [-I dir_containing_your_project-specific_m4_macros] $ autoconf $ autoheader $ automake -a

For Makefile-based projects, the cross-toolchain environment variables established by running the cross-toolchain environment setup script are subject to general make rules. To illustrate this, consider the following four cross-toolchain environment variables: CC=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux LD=i586-poky-linux-ld --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux CFLAGS=-O2 -pipe -g -feliminate-unused-debug-types CXXFLAGS=-O2 -pipe -g -feliminate-unused-debug-types Now, consider the following three cases: Case 1 - No Variables Set in the Makefile: Because these variables are not specifically set in the Makefile, the variables retain their values based on the environment. Case 2 - Variables Set in the Makefile: Specifically setting variables in the Makefile during the build results in the environment settings of the variables being overwritten. Case 3 - Variables Set when the Makefile is Executed from the Command Line: Executing the Makefile from the command line results in the variables being overwritten with command-line content regardless of what is being set in the Makefile. In this case, environment variables are not considered unless you use the "-e" flag during the build: $ make -e file If you use this flag, then the environment values of the variables override any variables specifically set in the Makefile. For the list of variables set up by the cross-toolchain environment setup script, see the "Running the SDK Environment Setup Script" section.

Describe the specific task you are going to accomplish with the SDK. Provide a diagram showing the rough flow of the task. Provide specific steps using a real example that works through the task.

Describe the specific task you are going to accomplish with the SDK. Provide a diagram showing the rough flow of the task. Provide specific steps using a real example that works through the task.

Describe the specific task you are going to accomplish with the SDK. Provide a diagram showing the rough flow of the task. Provide specific steps using a real example that works through the task.

Describe the specific task you are going to accomplish with the SDK. Provide a diagram showing the rough flow of the task. Provide specific steps using a real example that works through the task.