sdk-working-projects.rst 14 KB

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