diff options
Diffstat (limited to 'documentation/sdk-manual/sdk-working-projects.rst')
| -rw-r--r-- | documentation/sdk-manual/sdk-working-projects.rst | 284 |
1 files changed, 284 insertions, 0 deletions
diff --git a/documentation/sdk-manual/sdk-working-projects.rst b/documentation/sdk-manual/sdk-working-projects.rst new file mode 100644 index 0000000000..42f8bfeb46 --- /dev/null +++ b/documentation/sdk-manual/sdk-working-projects.rst | |||
| @@ -0,0 +1,284 @@ | |||
| 1 | ******************************** | ||
| 2 | Using the SDK Toolchain Directly | ||
| 3 | ******************************** | ||
| 4 | |||
| 5 | You can use the SDK toolchain directly with Makefile and Autotools-based | ||
| 6 | projects. | ||
| 7 | |||
| 8 | Autotools-Based Projects | ||
| 9 | ======================== | ||
| 10 | |||
| 11 | Once you have a suitable `cross-development | ||
| 12 | toolchain <&YOCTO_DOCS_REF_URL;#cross-development-toolchain>`__ | ||
| 13 | installed, it is very easy to develop a project using the `GNU | ||
| 14 | Autotools-based <https://en.wikipedia.org/wiki/GNU_Build_System>`__ | ||
| 15 | workflow, which is outside of the `OpenEmbedded build | ||
| 16 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. | ||
| 17 | |||
| 18 | The following figure presents a simple Autotools workflow. | ||
| 19 | |||
| 20 | Follow these steps to create a simple Autotools-based "Hello World" | ||
| 21 | project: | ||
| 22 | |||
| 23 | .. note:: | ||
| 24 | |||
| 25 | For more information on the GNU Autotools workflow, see the same | ||
| 26 | example on the | ||
| 27 | GNOME Developer | ||
| 28 | site. | ||
| 29 | |||
| 30 | 1. *Create a Working Directory and Populate It:* Create a clean | ||
| 31 | directory for your project and then make that directory your working | ||
| 32 | location. $ mkdir $HOME/helloworld $ cd $HOME/helloworld After | ||
| 33 | setting up the directory, populate it with files needed for the flow. | ||
| 34 | You need a project source file, a file to help with configuration, | ||
| 35 | and a file to help create the Makefile, and a README file: | ||
| 36 | ``hello.c``, ``configure.ac``, ``Makefile.am``, and ``README``, | ||
| 37 | respectively. | ||
| 38 | |||
| 39 | Use the following command to create an empty README file, which is | ||
| 40 | required by GNU Coding Standards: $ touch README Create the remaining | ||
| 41 | three files as follows: | ||
| 42 | |||
| 43 | - *``hello.c``:* #include <stdio.h> main() { printf("Hello | ||
| 44 | World!\n"); } | ||
| 45 | |||
| 46 | - *``configure.ac``:* AC_INIT(hello,0.1) AM_INIT_AUTOMAKE([foreign]) | ||
| 47 | AC_PROG_CC AC_CONFIG_FILES(Makefile) AC_OUTPUT | ||
| 48 | |||
| 49 | - *``Makefile.am``:* bin_PROGRAMS = hello hello_SOURCES = hello.c | ||
| 50 | |||
| 51 | 2. *Source the Cross-Toolchain Environment Setup File:* As described | ||
| 52 | earlier in the manual, installing the cross-toolchain creates a | ||
| 53 | cross-toolchain environment setup script in the directory that the | ||
| 54 | SDK was installed. Before you can use the tools to develop your | ||
| 55 | project, you must source this setup script. The script begins with | ||
| 56 | the string "environment-setup" and contains the machine architecture, | ||
| 57 | which is followed by the string "poky-linux". For this example, the | ||
| 58 | command sources a script from the default SDK installation directory | ||
| 59 | that uses the 32-bit Intel x86 Architecture and the DISTRO_NAME Yocto | ||
| 60 | Project release: $ source | ||
| 61 | /opt/poky/DISTRO/environment-setup-i586-poky-linux | ||
| 62 | |||
| 63 | 3. *Create the ``configure`` Script:* Use the ``autoreconf`` command to | ||
| 64 | generate the ``configure`` script. $ autoreconf The ``autoreconf`` | ||
| 65 | tool takes care of running the other Autotools such as ``aclocal``, | ||
| 66 | ``autoconf``, and ``automake``. | ||
| 67 | |||
| 68 | .. note:: | ||
| 69 | |||
| 70 | If you get errors from | ||
| 71 | configure.ac | ||
| 72 | , which | ||
| 73 | autoreconf | ||
| 74 | runs, that indicate missing files, you can use the "-i" option, | ||
| 75 | which ensures missing auxiliary files are copied to the build | ||
| 76 | host. | ||
| 77 | |||
| 78 | 4. *Cross-Compile the Project:* This command compiles the project using | ||
| 79 | the cross-compiler. The | ||
| 80 | ```CONFIGURE_FLAGS`` <&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS>`__ | ||
| 81 | environment variable provides the minimal arguments for GNU | ||
| 82 | configure: $ ./configure ${CONFIGURE_FLAGS} For an Autotools-based | ||
| 83 | project, you can use the cross-toolchain by just passing the | ||
| 84 | appropriate host option to ``configure.sh``. The host option you use | ||
| 85 | is derived from the name of the environment setup script found in the | ||
| 86 | directory in which you installed the cross-toolchain. For example, | ||
| 87 | the host option for an ARM-based target that uses the GNU EABI is | ||
| 88 | ``armv5te-poky-linux-gnueabi``. You will notice that the name of the | ||
| 89 | script is ``environment-setup-armv5te-poky-linux-gnueabi``. Thus, the | ||
| 90 | following command works to update your project and rebuild it using | ||
| 91 | the appropriate cross-toolchain tools: $ ./configure | ||
| 92 | --host=armv5te-poky-linux-gnueabi --with-libtool-sysroot=sysroot_dir | ||
| 93 | |||
| 94 | 5. *Make and Install the Project:* These two commands generate and | ||
| 95 | install the project into the destination directory: $ make $ make | ||
| 96 | install DESTDIR=./tmp | ||
| 97 | |||
| 98 | .. note:: | ||
| 99 | |||
| 100 | To learn about environment variables established when you run the | ||
| 101 | cross-toolchain environment setup script and how they are used or | ||
| 102 | overridden when the Makefile, see the " | ||
| 103 | Makefile-Based Projects | ||
| 104 | " section. | ||
| 105 | |||
| 106 | This next command is a simple way to verify the installation of your | ||
| 107 | project. Running the command prints the architecture on which the | ||
| 108 | binary file can run. This architecture should be the same | ||
| 109 | architecture that the installed cross-toolchain supports. $ file | ||
| 110 | ./tmp/usr/local/bin/hello | ||
| 111 | |||
| 112 | 6. *Execute Your Project:* To execute the project, you would need to run | ||
| 113 | it on your target hardware. If your target hardware happens to be | ||
| 114 | your build host, you could run the project as follows: $ | ||
| 115 | ./tmp/usr/local/bin/hello As expected, the project displays the | ||
| 116 | "Hello World!" message. | ||
| 117 | |||
| 118 | Makefile-Based Projects | ||
| 119 | ======================= | ||
| 120 | |||
| 121 | Simple Makefile-based projects use and interact with the cross-toolchain | ||
| 122 | environment variables established when you run the cross-toolchain | ||
| 123 | environment setup script. The environment variables are subject to | ||
| 124 | general ``make`` rules. | ||
| 125 | |||
| 126 | This section presents a simple Makefile development flow and provides an | ||
| 127 | example that lets you see how you can use cross-toolchain environment | ||
| 128 | variables and Makefile variables during development. | ||
| 129 | |||
| 130 | The main point of this section is to explain the following three cases | ||
| 131 | regarding variable behavior: | ||
| 132 | |||
| 133 | - *Case 1 - No Variables Set in the ``Makefile`` Map to Equivalent | ||
| 134 | Environment Variables Set in the SDK Setup Script:* Because matching | ||
| 135 | variables are not specifically set in the ``Makefile``, the variables | ||
| 136 | retain their values based on the environment setup script. | ||
| 137 | |||
| 138 | - *Case 2 - Variables Are Set in the Makefile that Map to Equivalent | ||
| 139 | Environment Variables from the SDK Setup Script:* Specifically | ||
| 140 | setting matching variables in the ``Makefile`` during the build | ||
| 141 | results in the environment settings of the variables being | ||
| 142 | overwritten. In this case, the variables you set in the ``Makefile`` | ||
| 143 | are used. | ||
| 144 | |||
| 145 | - *Case 3 - Variables Are Set Using the Command Line that Map to | ||
| 146 | Equivalent Environment Variables from the SDK Setup Script:* | ||
| 147 | Executing the ``Makefile`` from the command line results in the | ||
| 148 | environment variables being overwritten. In this case, the | ||
| 149 | command-line content is used. | ||
| 150 | |||
| 151 | .. note:: | ||
| 152 | |||
| 153 | Regardless of how you set your variables, if you use the "-e" option | ||
| 154 | with | ||
| 155 | make | ||
| 156 | , the variables from the SDK setup script take precedence: | ||
| 157 | :: | ||
| 158 | |||
| 159 | $ make -e target | ||
| 160 | |||
| 161 | |||
| 162 | The remainder of this section presents a simple Makefile example that | ||
| 163 | demonstrates these variable behaviors. | ||
| 164 | |||
| 165 | In a new shell environment variables are not established for the SDK | ||
| 166 | until you run the setup script. For example, the following commands show | ||
| 167 | a null value for the compiler variable (i.e. | ||
| 168 | ```CC`` <&YOCTO_DOCS_REF_URL;#var-CC>`__). $ echo ${CC} $ Running the | ||
| 169 | SDK setup script for a 64-bit build host and an i586-tuned target | ||
| 170 | architecture for a ``core-image-sato`` image using the current DISTRO | ||
| 171 | Yocto Project release and then echoing that variable shows the value | ||
| 172 | established through the script: $ source | ||
| 173 | /opt/poky/DISTRO/environment-setup-i586-poky-linux $ echo ${CC} | ||
| 174 | i586-poky-linux-gcc -m32 -march=i586 | ||
| 175 | --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux | ||
| 176 | |||
| 177 | To illustrate variable use, work through this simple "Hello World!" | ||
| 178 | example: | ||
| 179 | |||
| 180 | 1. *Create a Working Directory and Populate It:* Create a clean | ||
| 181 | directory for your project and then make that directory your working | ||
| 182 | location. $ mkdir $HOME/helloworld $ cd $HOME/helloworld After | ||
| 183 | setting up the directory, populate it with files needed for the flow. | ||
| 184 | You need a ``main.c`` file from which you call your function, a | ||
| 185 | ``module.h`` file to contain headers, and a ``module.c`` that defines | ||
| 186 | your function. | ||
| 187 | |||
| 188 | Create the three files as follows: | ||
| 189 | |||
| 190 | - *``main.c``:* #include "module.h" void sample_func(); int main() { | ||
| 191 | sample_func(); return 0; } | ||
| 192 | |||
| 193 | - *``module.h``:* #include <stdio.h> void sample_func(); | ||
| 194 | |||
| 195 | - *``module.c``:* #include "module.h" void sample_func() { | ||
| 196 | printf("Hello World!"); printf("\n"); } | ||
| 197 | |||
| 198 | 2. *Source the Cross-Toolchain Environment Setup File:* As described | ||
| 199 | earlier in the manual, installing the cross-toolchain creates a | ||
| 200 | cross-toolchain environment setup script in the directory that the | ||
| 201 | SDK was installed. Before you can use the tools to develop your | ||
| 202 | project, you must source this setup script. The script begins with | ||
| 203 | the string "environment-setup" and contains the machine architecture, | ||
| 204 | which is followed by the string "poky-linux". For this example, the | ||
| 205 | command sources a script from the default SDK installation directory | ||
| 206 | that uses the 32-bit Intel x86 Architecture and the DISTRO_NAME Yocto | ||
| 207 | Project release: $ source | ||
| 208 | /opt/poky/DISTRO/environment-setup-i586-poky-linux | ||
| 209 | |||
| 210 | 3. *Create the ``Makefile``:* For this example, the Makefile contains | ||
| 211 | two lines that can be used to set the ``CC`` variable. One line is | ||
| 212 | identical to the value that is set when you run the SDK environment | ||
| 213 | setup script, and the other line sets ``CC`` to "gcc", the default | ||
| 214 | GNU compiler on the build host: # CC=i586-poky-linux-gcc -m32 | ||
| 215 | -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux # | ||
| 216 | CC="gcc" all: main.o module.o ${CC} main.o module.o -o target_bin | ||
| 217 | main.o: main.c module.h ${CC} -I . -c main.c module.o: module.c | ||
| 218 | module.h ${CC} -I . -c module.c clean: rm -rf \*.o rm target_bin | ||
| 219 | |||
| 220 | 4. *Make the Project:* Use the ``make`` command to create the binary | ||
| 221 | output file. Because variables are commented out in the Makefile, the | ||
| 222 | value used for ``CC`` is the value set when the SDK environment setup | ||
| 223 | file was run: $ make i586-poky-linux-gcc -m32 -march=i586 | ||
| 224 | --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c main.c | ||
| 225 | i586-poky-linux-gcc -m32 -march=i586 | ||
| 226 | --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c module.c | ||
| 227 | i586-poky-linux-gcc -m32 -march=i586 | ||
| 228 | --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o | ||
| 229 | target_bin From the results of the previous command, you can see that | ||
| 230 | the compiler used was the compiler established through the ``CC`` | ||
| 231 | variable defined in the setup script. | ||
| 232 | |||
| 233 | You can override the ``CC`` environment variable with the same | ||
| 234 | variable as set from the Makefile by uncommenting the line in the | ||
| 235 | Makefile and running ``make`` again. $ make clean rm -rf \*.o rm | ||
| 236 | target_bin # # Edit the Makefile by uncommenting the line that sets | ||
| 237 | CC to "gcc" # $ make gcc -I . -c main.c gcc -I . -c module.c gcc | ||
| 238 | main.o module.o -o target_bin As shown in the previous example, the | ||
| 239 | cross-toolchain compiler is not used. Rather, the default compiler is | ||
| 240 | used. | ||
| 241 | |||
| 242 | This next case shows how to override a variable by providing the | ||
| 243 | variable as part of the command line. Go into the Makefile and | ||
| 244 | re-insert the comment character so that running ``make`` uses the | ||
| 245 | established SDK compiler. However, when you run ``make``, use a | ||
| 246 | command-line argument to set ``CC`` to "gcc": $ make clean rm -rf | ||
| 247 | \*.o rm target_bin # # Edit the Makefile to comment out the line | ||
| 248 | setting CC to "gcc" # $ make i586-poky-linux-gcc -m32 -march=i586 | ||
| 249 | --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c main.c | ||
| 250 | i586-poky-linux-gcc -m32 -march=i586 | ||
| 251 | --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c module.c | ||
| 252 | i586-poky-linux-gcc -m32 -march=i586 | ||
| 253 | --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o | ||
| 254 | target_bin $ make clean rm -rf \*.o rm target_bin $ make CC="gcc" gcc | ||
| 255 | -I . -c main.c gcc -I . -c module.c gcc main.o module.o -o target_bin | ||
| 256 | In the previous case, the command-line argument overrides the SDK | ||
| 257 | environment variable. | ||
| 258 | |||
| 259 | In this last case, edit Makefile again to use the "gcc" compiler but | ||
| 260 | then use the "-e" option on the ``make`` command line: $ make clean | ||
| 261 | rm -rf \*.o rm target_bin # # Edit the Makefile to use "gcc" # $ make | ||
| 262 | gcc -I . -c main.c gcc -I . -c module.c gcc main.o module.o -o | ||
| 263 | target_bin $ make clean rm -rf \*.o rm target_bin $ make -e | ||
| 264 | i586-poky-linux-gcc -m32 -march=i586 | ||
| 265 | --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c main.c | ||
| 266 | i586-poky-linux-gcc -m32 -march=i586 | ||
| 267 | --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c module.c | ||
| 268 | i586-poky-linux-gcc -m32 -march=i586 | ||
| 269 | --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o | ||
| 270 | target_bin In the previous case, the "-e" option forces ``make`` to | ||
| 271 | use the SDK environment variables regardless of the values in the | ||
| 272 | Makefile. | ||
| 273 | |||
| 274 | 5. *Execute Your Project:* To execute the project (i.e. ``target_bin``), | ||
| 275 | use the following command: $ ./target_bin Hello World! | ||
| 276 | |||
| 277 | .. note:: | ||
| 278 | |||
| 279 | If you used the cross-toolchain compiler to build | ||
| 280 | target_bin | ||
| 281 | and your build host differs in architecture from that of the | ||
| 282 | target machine, you need to run your project on the target device. | ||
| 283 | |||
| 284 | As expected, the project displays the "Hello World!" message. | ||
