%poky; ] > Using the SDK Toolchain Directly You can use the SDK toolchain directly with Makefile, Autotools, and Eclipse-based projects. This chapter covers the first two, while the "Developing Applications Using Eclipse" Chapter covers the latter.
Autotools-Based Projects Once you have a suitable cross-development toolchain installed, it is very easy to develop a project using the GNU Autotools-based workflow, which is outside of the OpenEmbedded build system. The following figure presents a simple Autotools workflow. Follow these steps to create a simple Autotools-based "Hello World" project: For more information on the GNU Autotools workflow, see the same example on the GNOME Developer site. Create a Working Directory and Populate It: Create a clean directory for your project and then make that directory your working location. $ mkdir $HOME/helloworld $ cd $HOME/helloworld After setting up the directory, populate it with three simple files needed for the flow. You need a project source file, a file to help with configuration, and a file to help create the Makefile: hello.c, configure.ac, and Makefile.am, respectively: hello.c: #include <stdio.h> main() { printf("Hello World!\n"); } configure.ac: AC_INIT(hello,0.1) AM_INIT_AUTOMAKE([foreign]) AC_PROG_CC AC_CONFIG_FILES(Makefile) AC_OUTPUT Makefile.am: bin_PROGRAMS = hello hello_SOURCES = hello.c Source the Cross-Toolchain Environment Setup File: As described earlier in the manual, installing the cross-toolchain creates a cross-toolchain environment setup script in the directory that the SDK 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". For this example, the command sources a script from the default SDK 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: The following command generates the local aclocal.m4 files, which are used later with the autoconf command: $ aclocal Create the configure Script: The following command creates the configure script: $ 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 Makefile.in File: This command generates the Makefile.in, which is used later during cross-compilation: $ 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} 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_TARGET_SYSROOT}/usr/share/aclocal [-I dir_containing_your_project-specific_m4_macros] $ autoconf $ autoheader $ automake -a Make and Install the Project: These two commands generate and install the project into the destination directory: $ make $ make install DESTDIR=./tmp To learn about environment variables established when you run the cross-toolchain environment setup script and how they are used or overridden when the Makefile, see the "Makefile-Based Projects" section. This next 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.
Makefile-Based Projects Simple Makefile-based projects use and interact with the cross-toolchain environment variables established when you run the cross-toolchain environment setup script. The environment variables are subject to general make rules. This section presents a simple Makefile development flow and provides an example that lets you see how you can use cross-toolchain environment variables to replace or override variables used in your Makefile. The main point of this section is to explain the following three cases regarding variable behavior: Case 1 - No Variables Set in the Makefile that Map to Equivalent Environment Variables Set in the SDK Setup Script: Because matching variables are not specifically set in the Makefile, the variables retain their values based on the environment setup script. Case 2 - Variables Are Set in the Makefile that Map to Equivalent Environment Variables from the SDK Setup Script: Specifically setting matching variables in the Makefile during the build results in the environment settings of the variables being overwritten. In this case, the variables you set in the Makefile are used. Case 3 - Variables Are Set Using the Command Line that Map to Equivalent Environment Variables from the SDK Setup Script: Executing the Makefile from the command line results in the environment settings of the variables being overwritten. In this case, the command-line content is used. The one exception to this is if you use the following command-line option: $ make -e target Using the "-e" option with make causes the environment variables to be used during the build. The remainder of this section presents a simple Makefile example that demonstrates these variable behaviors. In a new shell environment variables are not established for the SDK until you run the setup script. For example, the following commands show null values for four variables that are set when you run the SDK environment setup script for a 64-bit build host and an i586-tuned target architecture for a core-image-sato image using the current &DISTRO; Yocto Project release: $ echo ${CC} $ echo ${LD} $ echo ${CFLAGS} $ echo ${CXXFLAGS} Running the setup script and then echoing the variables shows the values established for the SDK: $ source /opt/poky/2.5/environment-setup-i586-poky-linux $ echo ${CC} i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux $ echo ${LD} i586-poky-linux-ld --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux $ echo ${CFLAGS} -O2 -pipe -g -feliminate-unused-debug-types $ echo ${CXXFLAGS} -O2 -pipe -g -feliminate-unused-debug-types NEED REST OF THE EXAMPLE. WORKING ON GETTING IT TO WORK PROPERLY.