From 0bb6e48a334d8ab7bedb7da9444a3a1b812ef996 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Wed, 2 Mar 2016 08:48:50 -0800 Subject: sdk-manual: WIP on the book. (From yocto-docs rev: 140577dd1f91c096152354e711709efe64bbcd0e) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/sdk-manual/sdk-using.xml | 297 ++++++++++++++++++++++++++------- 1 file changed, 240 insertions(+), 57 deletions(-) (limited to 'documentation/sdk-manual/sdk-using.xml') diff --git a/documentation/sdk-manual/sdk-using.xml b/documentation/sdk-manual/sdk-using.xml index 66f2c0ed9d..f2acaa7fc4 100644 --- a/documentation/sdk-manual/sdk-using.xml +++ b/documentation/sdk-manual/sdk-using.xml @@ -23,8 +23,9 @@
Why use the Standard SDK and What is in It? - - MANUAL DEVELOPMENT NOTES: + + 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. @@ -37,46 +38,6 @@ If there is more detail, I need to know about it. - - MANUAL DEVELOPMENT NOTES: - Here is a list of items I think need addressed in these early - sections: - - What is your situation? - In other words, is the developer on a machine that - has YP on it? - Are they on a machine that does not? - Is the image they are developing against available as a - pre-built, down-loadable image and can they get it? - Depending on the scenario, there are different ways - to make sure the machine they are using is ready to use a - standard SDK. - I think we need to cover the various situations in this - section. - - What are the recommendations? - What is the most common development scenario? - Is there a recommended development flow we want to present - when using a standard SDK? - What conditions in a development scenario warrant use of - just the standard SDK as compared to the extensible SDK? - - What procedures do we want to cover to set up - the standard SDK? - There is a ton of setup information in the - current ADT manual regarding getting, building, and installing - an SDK. - We would ignore the stuff about the ADT installer script - since I presume that is going away. - But, there are steps to download and existing - .sh install script, build out the - toolchains assuming your system has YP on it and you can run - BitBake, getting the root filesystem, getting an image so you - run QEMU on your system, etc. - - - - The installed Standard SDK consists of several files and directories. Basically, it contains an SDK environment setup script, some @@ -161,15 +122,16 @@ 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. - When you run the installer, the script prompts you for a - system password so that you permissions can change enabling - you to run the installer script. The example assumes the toolchain installer is located in ~/Downloads/. @@ -180,17 +142,16 @@ run the installer again. - $ ~/Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh - Poky (Yocto Project Reference Distro) SDK installer version 2.1+snapshot - ======================================================================== - Enter target directory for SDK (default: /opt/poky/2.1+snapshot): - You are about to install the SDK to "/opt/poky/2.1+snapshot". Proceed[Y/n]? Y - [sudo] password for scottrif: - Extracting SDK.......................done + $ ./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+snapshot/environment-setup-i586-poky-linux + $ . /opt/poky/2.1/environment-setup-i586-poky-linux @@ -221,11 +182,11 @@ Environment setup scripts begin with the string "environment-setup" and include as part of their name the tuned target architecture. - For example, the setup script for an IA-based target machine using - i586 tuning and located in the default SDK installation - directory is as follows: + 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;+snapshot/environment-setup-i586-poky-linux + $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux When you run the setup script, many environment variables are defined: @@ -256,6 +217,228 @@
+
+ Autotools-Based Projects + + + 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. + + +
+ Creating and Running a Project Based on GNU Autotools + + + 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. + + + +
+ +
+ Passing Host Options + + + 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 + + + +
+
+ +
+ Makefile-Based Projects + + + 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. + + +
+
Using the SDK to <replaceable>item 1</replaceable> -- cgit v1.2.3-54-g00ecf