working-projects.rst 14 KB

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