path: root/documentation/sdk-manual/sdk-using.xml

<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >

<chapter id='sdk-using-the-standard-sdk'>

<title>Using the Standard SDK</title>

<para>
    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.
    <note>
        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
        "<link linkend='sdk-extensible'>Using the Extensible SDK</link>"
        chapter.
    </note>
</para>

<section id='sdk-standard-sdk-intro'>
    <title>Why use the Standard SDK and What is in It?</title>

    <para>
        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.
    </para>

    <para>
        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
        "<link linkend='sdk-installed-standard-sdk-directory-structure'>Installed Standard SDK Directory Structure</link>"
        section.
        <note>
            You can also find information on how the Yocto Project
            OpenEmbedded build system creates an SDK image by looking at the
            "<ulink url='&YOCTO_DOCS_REF_URL;#sdk-generation-dev-environment'>SDK Generation</ulink>"
            section in the Yocto Project Reference Manual.
        </note>
    </para>
</section>

<section id='sdk-installing-the-sdk'>
    <title>Installing the SDK</title>

    <para>
        The first thing you need to do is install the SDK on your host
        development machine by running the <filename>.sh</filename>
        installation script.
    </para>

    <para>
        You can download a tarball installer, which includes the
        pre-built toolchain, the <filename>runqemu</filename>
        script, and support files from the appropriate directory under
        <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>.
        Toolchains are available for 32-bit and 64-bit x86 development
        systems from the <filename>i686</filename> and
        <filename>x86_64</filename> directories, respectively.
        The toolchains the Yocto Project provides are based off the
        <filename>core-image-sato</filename> image and contain
        libraries appropriate for developing against that image.
        Each type of development system supports five or more target
        architectures.
    </para>

    <para>
        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.
        <literallayout class='monospaced'>
     poky-glibc-<replaceable>host_system</replaceable>-<replaceable>image_type</replaceable>-<replaceable>arch</replaceable>-toolchain-<replaceable>release_version</replaceable>.sh

     Where:
         <replaceable>host_system</replaceable> is a string representing your development system:

                    i686 or x86_64.

         <replaceable>image_type</replaceable> 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

         <replaceable>arch</replaceable> is a string representing the tuned target architecture:

                    i586, x86_64, powerpc, mips, armv7a or armv5te

         <replaceable>release_version</replaceable> is a string representing the release number of the
                Yocto Project:

                    &DISTRO;, &DISTRO;+snapshot
        </literallayout>
        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 <filename>core-image-sato</filename> and
        using the current &DISTRO; snapshot:
        <literallayout class='monospaced'>
     poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
        </literallayout>
    </para>

    <para>
        The SDK and toolchains are self-contained and by default are installed
        into <filename>/opt/poky</filename>.
        However, when you run the SDK installer, you can choose an
        installation directory.
        <note>
            You must change the permissions on the toolchain
            installer script so that it is executable.
        </note>
    </para>

    <para>
        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
        <filename>~/Downloads/</filename>.
        <note>
            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.
        </note>
        <literallayout class='monospaced'>
     $ ./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
        </literallayout>
    </para>

    <para>
        Again, reference the
        "<link linkend='sdk-installed-standard-sdk-directory-structure'>Installed Standard SDK Directory Structure</link>"
        section for more details on the resulting directory structure of
        the installed SDK.
    </para>
</section>

<section id='sdk-running-the-sdk-environment-setup-script'>
    <title>Running the SDK Environment Setup Script</title>

    <para>
        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
        "<link linkend='sdk-appendix-obtain'>Obtaining the SDK</link>"
        Appendix.
    </para>

    <para>
        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
        "<filename>environment-setup</filename>" 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:
        <literallayout class='monospaced'>
     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
        </literallayout>
        When you run the setup script, many environment variables are
        defined:
        <literallayout class='monospaced'>
     <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKTARGETSYSROOT'><filename>SDKTARGETSYSROOT</filename></ulink> - The path to the sysroot used for cross-compilation
     <ulink url='&YOCTO_DOCS_REF_URL;#var-PKG_CONFIG_PATH'><filename>PKG_CONFIG_PATH</filename></ulink> - The path to the target pkg-config files
     <ulink url='&YOCTO_DOCS_REF_URL;#var-CONFIG_SITE'><filename>CONFIG_SITE</filename></ulink> - A GNU autoconf site file preconfigured for the target
     <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink> - The minimal command and arguments to run the C compiler
     <ulink url='&YOCTO_DOCS_REF_URL;#var-CXX'><filename>CXX</filename></ulink> - The minimal command and arguments to run the C++ compiler
     <ulink url='&YOCTO_DOCS_REF_URL;#var-CPP'><filename>CPP</filename></ulink> - The minimal command and arguments to run the C preprocessor
     <ulink url='&YOCTO_DOCS_REF_URL;#var-AS'><filename>AS</filename></ulink> - The minimal command and arguments to run the assembler
     <ulink url='&YOCTO_DOCS_REF_URL;#var-LD'><filename>LD</filename></ulink> - The minimal command and arguments to run the linker
     <ulink url='&YOCTO_DOCS_REF_URL;#var-GDB'><filename>GDB</filename></ulink> - The minimal command and arguments to run the GNU Debugger
     <ulink url='&YOCTO_DOCS_REF_URL;#var-STRIP'><filename>STRIP</filename></ulink> - The minimal command and arguments to run 'strip', which strips symbols
     <ulink url='&YOCTO_DOCS_REF_URL;#var-RANLIB'><filename>RANLIB</filename></ulink> - The minimal command and arguments to run 'ranlib'
     <ulink url='&YOCTO_DOCS_REF_URL;#var-OBJCOPY'><filename>OBJCOPY</filename></ulink> - The minimal command and arguments to run 'objcopy'
     <ulink url='&YOCTO_DOCS_REF_URL;#var-OBJDUMP'><filename>OBJDUMP</filename></ulink> - The minimal command and arguments to run 'objdump'
     <ulink url='&YOCTO_DOCS_REF_URL;#var-AR'><filename>AR</filename></ulink> - The minimal command and arguments to run 'ar'
     <ulink url='&YOCTO_DOCS_REF_URL;#var-NM'><filename>NM</filename></ulink> - The minimal command and arguments to run 'nm'
     <ulink url='&YOCTO_DOCS_REF_URL;#var-TARGET_PREFIX'><filename>TARGET_PREFIX</filename></ulink> - The toolchain binary prefix for the target tools
     <ulink url='&YOCTO_DOCS_REF_URL;#var-CROSS_COMPILE'><filename>CROSS_COMPILE</filename></ulink> - The toolchain binary prefix for the target tools
     <ulink url='&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS'><filename>CONFIGURE_FLAGS</filename></ulink> - The minimal arguments for GNU configure
     <ulink url='&YOCTO_DOCS_REF_URL;#var-CFLAGS'><filename>CFLAGS</filename></ulink> - Suggested C flags
     <ulink url='&YOCTO_DOCS_REF_URL;#var-CXXFLAGS'><filename>CXXFLAGS</filename></ulink> - Suggested C++ flags
     <ulink url='&YOCTO_DOCS_REF_URL;#var-LDFLAGS'><filename>LDFLAGS</filename></ulink> - Suggested linker flags when you use CC to link
     <ulink url='&YOCTO_DOCS_REF_URL;#var-CPPFLAGS'><filename>CPPFLAGS</filename></ulink> - Suggested preprocessor flags
        </literallayout>
    </para>
</section>

<section id='autotools-based-projects'>
    <title>Autotools-Based Projects</title>

    <para>
        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.
    </para>

    <section id='creating-and-running-a-project-based-on-gnu-autotools'>
        <title>Creating and Running a Project Based on GNU Autotools</title>

        <para>
            Follow these steps to create a simple Autotools-based project:
            <orderedlist>
                <listitem><para><emphasis>Create your directory:</emphasis>
                    Create a clean directory for your project and then make
                    that directory your working location:
                    <literallayout class='monospaced'>
     $ mkdir $HOME/helloworld
     $ cd $HOME/helloworld
                    </literallayout></para></listitem>
                <listitem><para><emphasis>Populate the directory:</emphasis>
                    Create <filename>hello.c</filename>, <filename>Makefile.am</filename>,
                    and <filename>configure.in</filename> files as follows:
                    <itemizedlist>
                        <listitem><para>For <filename>hello.c</filename>, include
                            these lines:
                            <literallayout class='monospaced'>
     #include &lt;stdio.h&gt;

     main()
        {
           printf("Hello World!\n");
        }
                            </literallayout></para></listitem>
                        <listitem><para>For <filename>Makefile.am</filename>,
                            include these lines:
                            <literallayout class='monospaced'>
     bin_PROGRAMS = hello
     hello_SOURCES = hello.c
                            </literallayout></para></listitem>
                        <listitem><para>For <filename>configure.in</filename>,
                            include these lines:
                            <literallayout class='monospaced'>
     AC_INIT(hello.c)
     AM_INIT_AUTOMAKE(hello,0.1)
     AC_PROG_CC
     AC_PROG_INSTALL
     AC_OUTPUT(Makefile)
                            </literallayout></para></listitem>
                    </itemizedlist></para></listitem>
                <listitem><para><emphasis>Source the cross-toolchain
                    environment setup file:</emphasis>
                    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:
                    <literallayout class='monospaced'>
     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
                    </literallayout></para></listitem>
                <listitem><para><emphasis>Generate the local aclocal.m4
                    files and create the configure script:</emphasis>
                    The following GNU Autotools generate the local
                    <filename>aclocal.m4</filename> files and create the
                    configure script:
                    <literallayout class='monospaced'>
     $ aclocal
     $ autoconf
                    </literallayout></para></listitem>
                <listitem><para><emphasis>Generate files needed by GNU
                    coding standards:</emphasis>
                    GNU coding standards require certain files in order for the
                    project to be compliant.
                    This command creates those files:
                    <literallayout class='monospaced'>
     $ touch NEWS README AUTHORS ChangeLog
                    </literallayout></para></listitem>
                <listitem><para><emphasis>Generate the configure
                    file:</emphasis>
                    This command generates the <filename>configure</filename>:
                    <literallayout class='monospaced'>
     $ automake -a
                    </literallayout></para></listitem>
                <listitem><para><emphasis>Cross-compile the project:</emphasis>
                    This command compiles the project using the cross-compiler.
                    The
                    <ulink url='&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS'><filename>CONFIGURE_FLAGS</filename></ulink>
                    environment variable provides the minimal arguments for
                    GNU configure:
                    <literallayout class='monospaced'>
     $ ./configure ${CONFIGURE_FLAGS}
                    </literallayout></para></listitem>
                <listitem><para><emphasis>Make and install the project:</emphasis>
                    These two commands generate and install the project into the
                    destination directory:
                    <literallayout class='monospaced'>
     $ make
     $ make install DESTDIR=./tmp
                    </literallayout></para></listitem>
                <listitem><para><emphasis>Verify the installation:</emphasis>
                    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.
                    <literallayout class='monospaced'>
     $ file ./tmp/usr/local/bin/hello
                    </literallayout></para></listitem>
                <listitem><para><emphasis>Execute your project:</emphasis>
                    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:
                    <literallayout class='monospaced'>
     $ ./hello
                    </literallayout>
                    As expected, the project displays the "Hello World!" message.
                    </para></listitem>
            </orderedlist>
        </para>
    </section>

    <section id='passing-host-options'>
        <title>Passing Host Options</title>

        <para>
            For an Autotools-based project, you can use the cross-toolchain by just
            passing the appropriate host option to <filename>configure.sh</filename>.
            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 <filename>armv5te-poky-linux-gnueabi</filename>.
            You will notice that the name of the script is
            <filename>environment-setup-armv5te-poky-linux-gnueabi</filename>.
            Thus, the following command works to update your project and
            rebuild it using the appropriate cross-toolchain tools:
            <literallayout class='monospaced'>
     $ ./configure --host=armv5te-poky-linux-gnueabi \
        --with-libtool-sysroot=<replaceable>sysroot_dir</replaceable>
            </literallayout>
            <note>
                If the <filename>configure</filename> script results in problems recognizing the
                <filename>--with-libtool-sysroot=</filename><replaceable>sysroot-dir</replaceable> option,
                regenerate the script to enable the support by doing the following and then
                run the script again:
                <literallayout class='monospaced'>
     $ libtoolize --automake
     $ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \
        [-I <replaceable>dir_containing_your_project-specific_m4_macros</replaceable>]
     $ autoconf
     $ autoheader
     $ automake -a
                </literallayout>
            </note>
        </para>
    </section>
</section>

<section id='makefile-based-projects'>
    <title>Makefile-Based Projects</title>

    <para>
        For Makefile-based projects, the cross-toolchain environment variables
        established by running the cross-toolchain environment setup script
        are subject to general <filename>make</filename> rules.
    </para>

    <para>
        To illustrate this, consider the following four cross-toolchain
        environment variables:
        <literallayout class='monospaced'>
     <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'>CC</ulink>=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
     <ulink url='&YOCTO_DOCS_REF_URL;#var-LD'>LD</ulink>=i586-poky-linux-ld --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
     <ulink url='&YOCTO_DOCS_REF_URL;#var-CFLAGS'>CFLAGS</ulink>=-O2 -pipe -g -feliminate-unused-debug-types
     <ulink url='&YOCTO_DOCS_REF_URL;#var-CXXFLAGS'>CXXFLAGS</ulink>=-O2 -pipe -g -feliminate-unused-debug-types
        </literallayout>
        Now, consider the following three cases:
        <itemizedlist>
            <listitem><para><emphasis>Case 1 - No Variables Set in the <filename>Makefile</filename>:</emphasis>
                Because these variables are not specifically set in the
                <filename>Makefile</filename>, the variables retain their
                values based on the environment.
                </para></listitem>
            <listitem><para><emphasis>Case 2 - Variables Set in the <filename>Makefile</filename>:</emphasis>
                Specifically setting variables in the
                <filename>Makefile</filename> during the build results in the
                environment settings of the variables being overwritten.
                </para></listitem>
            <listitem><para><emphasis>Case 3 - Variables Set when the <filename>Makefile</filename> is Executed from the Command Line:</emphasis>
                Executing the <filename>Makefile</filename> from the command
                line results in the variables being overwritten with
                command-line content regardless of what is being set in the
                <filename>Makefile</filename>.
                In this case, environment variables are not considered unless
                you use the "-e" flag during the build:
                <literallayout class='monospaced'>
     $ make -e <replaceable>file</replaceable>
                </literallayout>
                If you use this flag, then the environment values of the
                variables override any variables specifically set in the
                <filename>Makefile</filename>.
                </para></listitem>
        </itemizedlist>
        <note>
            For the list of variables set up by the cross-toolchain environment
            setup script, see the
            "<link linkend='sdk-running-the-sdk-environment-setup-script'>Running the SDK Environment Setup Script</link>"
            section.
        </note>
    </para>
</section>

<section id='sdk-using-the-sdk-to-task-1'>
    <title>Using the SDK to <replaceable>item 1</replaceable></title>

    <para role='writernotes'>
        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.
    </para>
</section>

<section id='sdk-using-the-sdk-to-task-2'>
    <title>Using the SDK to <replaceable>item-2</replaceable></title>

    <para role='writernotes'>
        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.
    </para>
</section>

<section id='sdk-using-the-sdk-to-task-3'>
    <title>Using the SDK to <replaceable>item-3</replaceable></title>

    <para role='writernotes'>
        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.
    </para>
</section>

<section id='sdk-using-the-sdk-to-task-x'>
    <title>Using the SDK to <replaceable>item-x</replaceable></title>

    <para role='writernotes'>
        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.
    </para>
</section>

</chapter>
<!--
vim: expandtab tw=80 ts=4
-->