diff options
Diffstat (limited to 'documentation/ref-manual/faq.rst')
-rw-r--r-- | documentation/ref-manual/faq.rst | 418 |
1 files changed, 418 insertions, 0 deletions
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst new file mode 100644 index 0000000000..6d26537980 --- /dev/null +++ b/documentation/ref-manual/faq.rst | |||
@@ -0,0 +1,418 @@ | |||
1 | *** | ||
2 | FAQ | ||
3 | *** | ||
4 | |||
5 | **Q:** How does Poky differ from `OpenEmbedded <&OE_HOME_URL;>`__? | ||
6 | |||
7 | **A:** The term "`Poky <#>`__" refers to the specific reference build | ||
8 | system that the Yocto Project provides. Poky is based on | ||
9 | `OE-Core <#oe-core>`__ and `BitBake <#bitbake-term>`__. Thus, the | ||
10 | generic term used here for the build system is the "OpenEmbedded build | ||
11 | system." Development in the Yocto Project using Poky is closely tied to | ||
12 | OpenEmbedded, with changes always being merged to OE-Core or BitBake | ||
13 | first before being pulled back into Poky. This practice benefits both | ||
14 | projects immediately. | ||
15 | |||
16 | **Q:** My development system does not meet the required Git, tar, and | ||
17 | Python versions. In particular, I do not have Python 3.5.0 or greater. | ||
18 | Can I still use the Yocto Project? | ||
19 | |||
20 | **A:** You can get the required tools on your host development system a | ||
21 | couple different ways (i.e. building a tarball or downloading a | ||
22 | tarball). See the "`Required Git, tar, Python and gcc | ||
23 | Versions <#required-git-tar-python-and-gcc-versions>`__" section for | ||
24 | steps on how to update your build tools. | ||
25 | |||
26 | **Q:** How can you claim Poky / OpenEmbedded-Core is stable? | ||
27 | |||
28 | **A:** There are three areas that help with stability; | ||
29 | |||
30 | - The Yocto Project team keeps `OE-Core <#oe-core>`__ small and | ||
31 | focused, containing around 830 recipes as opposed to the thousands | ||
32 | available in other OpenEmbedded community layers. Keeping it small | ||
33 | makes it easy to test and maintain. | ||
34 | |||
35 | - The Yocto Project team runs manual and automated tests using a small, | ||
36 | fixed set of reference hardware as well as emulated targets. | ||
37 | |||
38 | - The Yocto Project uses an autobuilder, which provides continuous | ||
39 | build and integration tests. | ||
40 | |||
41 | **Q:** How do I get support for my board added to the Yocto Project? | ||
42 | |||
43 | **A:** Support for an additional board is added by creating a Board | ||
44 | Support Package (BSP) layer for it. For more information on how to | ||
45 | create a BSP layer, see the "`Understanding and Creating | ||
46 | Layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__" | ||
47 | section in the Yocto Project Development Tasks Manual and the `Yocto | ||
48 | Project Board Support Package (BSP) Developer's | ||
49 | Guide <&YOCTO_DOCS_BSP_URL;>`__. | ||
50 | |||
51 | Usually, if the board is not completely exotic, adding support in the | ||
52 | Yocto Project is fairly straightforward. | ||
53 | |||
54 | **Q:** Are there any products built using the OpenEmbedded build system? | ||
55 | |||
56 | **A:** The software running on the `Vernier | ||
57 | LabQuest <http://vernier.com/labquest/>`__ is built using the | ||
58 | OpenEmbedded build system. See the `Vernier | ||
59 | LabQuest <http://www.vernier.com/products/interfaces/labq/>`__ website | ||
60 | for more information. There are a number of pre-production devices using | ||
61 | the OpenEmbedded build system and the Yocto Project team announces them | ||
62 | as soon as they are released. | ||
63 | |||
64 | **Q:** What does the OpenEmbedded build system produce as output? | ||
65 | |||
66 | **A:** Because you can use the same set of recipes to create output of | ||
67 | various formats, the output of an OpenEmbedded build depends on how you | ||
68 | start it. Usually, the output is a flashable image ready for the target | ||
69 | device. | ||
70 | |||
71 | **Q:** How do I add my package to the Yocto Project? | ||
72 | |||
73 | **A:** To add a package, you need to create a BitBake recipe. For | ||
74 | information on how to create a BitBake recipe, see the "`Writing a New | ||
75 | Recipe <&YOCTO_DOCS_DEV_URL;#new-recipe-writing-a-new-recipe>`__" | ||
76 | section in the Yocto Project Development Tasks Manual. | ||
77 | |||
78 | **Q:** Do I have to reflash my entire board with a new Yocto Project | ||
79 | image when recompiling a package? | ||
80 | |||
81 | **A:** The OpenEmbedded build system can build packages in various | ||
82 | formats such as IPK for OPKG, Debian package (``.deb``), or RPM. You can | ||
83 | then upgrade the packages using the package tools on the device, much | ||
84 | like on a desktop distribution such as Ubuntu or Fedora. However, | ||
85 | package management on the target is entirely optional. | ||
86 | |||
87 | **Q:** I see the error | ||
88 | '``chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x``'. What is | ||
89 | wrong? | ||
90 | |||
91 | **A:** You are probably running the build on an NTFS filesystem. Use | ||
92 | ``ext2``, ``ext3``, or ``ext4`` instead. | ||
93 | |||
94 | **Q:** I see lots of 404 responses for files when the OpenEmbedded build | ||
95 | system is trying to download sources. Is something wrong? | ||
96 | |||
97 | **A:** Nothing is wrong. The OpenEmbedded build system checks any | ||
98 | configured source mirrors before downloading from the upstream sources. | ||
99 | The build system does this searching for both source archives and | ||
100 | pre-checked out versions of SCM-managed software. These checks help in | ||
101 | large installations because it can reduce load on the SCM servers | ||
102 | themselves. The address above is one of the default mirrors configured | ||
103 | into the build system. Consequently, if an upstream source disappears, | ||
104 | the team can place sources there so builds continue to work. | ||
105 | |||
106 | **Q:** I have machine-specific data in a package for one machine only | ||
107 | but the package is being marked as machine-specific in all cases, how do | ||
108 | I prevent this? | ||
109 | |||
110 | **A:** Set ``SRC_URI_OVERRIDES_PACKAGE_ARCH`` = "0" in the ``.bb`` file | ||
111 | but make sure the package is manually marked as machine-specific for the | ||
112 | case that needs it. The code that handles | ||
113 | ``SRC_URI_OVERRIDES_PACKAGE_ARCH`` is in the | ||
114 | ``meta/classes/base.bbclass`` file. | ||
115 | |||
116 | **Q:** I'm behind a firewall and need to use a proxy server. How do I do | ||
117 | that? | ||
118 | |||
119 | **A:** Most source fetching by the OpenEmbedded build system is done by | ||
120 | ``wget`` and you therefore need to specify the proxy settings in a | ||
121 | ``.wgetrc`` file, which can be in your home directory if you are a | ||
122 | single user or can be in ``/usr/local/etc/wgetrc`` as a global user | ||
123 | file. | ||
124 | |||
125 | Following is the applicable code for setting various proxy types in the | ||
126 | ``.wgetrc`` file. By default, these settings are disabled with comments. | ||
127 | To use them, remove the comments: # You can set the default proxies for | ||
128 | Wget to use for http, https, and ftp. # They will override the value in | ||
129 | the environment. #https_proxy = http://proxy.yoyodyne.com:18023/ | ||
130 | #http_proxy = http://proxy.yoyodyne.com:18023/ #ftp_proxy = | ||
131 | http://proxy.yoyodyne.com:18023/ # If you do not want to use proxy at | ||
132 | all, set this to off. #use_proxy = on The Yocto Project also includes a | ||
133 | ``meta-poky/conf/site.conf.sample`` file that shows how to configure CVS | ||
134 | and Git proxy servers if needed. For more information on setting up | ||
135 | various proxy types and configuring proxy servers, see the "`Working | ||
136 | Behind a Network | ||
137 | Proxy <&YOCTO_WIKI_URL;/wiki/Working_Behind_a_Network_Proxy>`__" Wiki | ||
138 | page. | ||
139 | |||
140 | **Q:** What’s the difference between target and target\ ``-native``? | ||
141 | |||
142 | **A:** The ``*-native`` targets are designed to run on the system being | ||
143 | used for the build. These are usually tools that are needed to assist | ||
144 | the build in some way such as ``quilt-native``, which is used to apply | ||
145 | patches. The non-native version is the one that runs on the target | ||
146 | device. | ||
147 | |||
148 | **Q:** I'm seeing random build failures. Help?! | ||
149 | |||
150 | **A:** If the same build is failing in totally different and random | ||
151 | ways, the most likely explanation is: | ||
152 | |||
153 | - The hardware you are running the build on has some problem. | ||
154 | |||
155 | - You are running the build under virtualization, in which case the | ||
156 | virtualization probably has bugs. | ||
157 | |||
158 | The OpenEmbedded build system processes a massive amount of data that | ||
159 | causes lots of network, disk and CPU activity and is sensitive to even | ||
160 | single-bit failures in any of these areas. True random failures have | ||
161 | always been traced back to hardware or virtualization issues. | ||
162 | |||
163 | **Q:** When I try to build a native recipe, the build fails with | ||
164 | ``iconv.h`` problems. | ||
165 | |||
166 | **A:** If you get an error message that indicates GNU ``libiconv`` is | ||
167 | not in use but ``iconv.h`` has been included from ``libiconv``, you need | ||
168 | to check to see if you have a previously installed version of the header | ||
169 | file in ``/usr/local/include``. #error GNU libiconv not in use but | ||
170 | included iconv.h is from libiconv If you find a previously installed | ||
171 | file, you should either uninstall it or temporarily rename it and try | ||
172 | the build again. | ||
173 | |||
174 | This issue is just a single manifestation of "system leakage" issues | ||
175 | caused when the OpenEmbedded build system finds and uses previously | ||
176 | installed files during a native build. This type of issue might not be | ||
177 | limited to ``iconv.h``. Be sure that leakage cannot occur from | ||
178 | ``/usr/local/include`` and ``/opt`` locations. | ||
179 | |||
180 | **Q:** What do we need to ship for license compliance? | ||
181 | |||
182 | **A:** This is a difficult question and you need to consult your lawyer | ||
183 | for the answer for your specific case. It is worth bearing in mind that | ||
184 | for GPL compliance, there needs to be enough information shipped to | ||
185 | allow someone else to rebuild and produce the same end result you are | ||
186 | shipping. This means sharing the source code, any patches applied to it, | ||
187 | and also any configuration information about how that package was | ||
188 | configured and built. | ||
189 | |||
190 | You can find more information on licensing in the | ||
191 | "`Licensing <&YOCTO_DOCS_OM_URL;#licensing>`__" section in the Yocto | ||
192 | Project Overview and Concepts Manual and also in the "`Maintaining Open | ||
193 | Source License Compliance During Your Product's | ||
194 | Lifecycle <&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle>`__" | ||
195 | section in the Yocto Project Development Tasks Manual. | ||
196 | |||
197 | **Q:** How do I disable the cursor on my touchscreen device? | ||
198 | |||
199 | **A:** You need to create a form factor file as described in the | ||
200 | "`Miscellaneous BSP-Specific Recipe | ||
201 | Files <&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes>`__" section in | ||
202 | the Yocto Project Board Support Packages (BSP) Developer's Guide. Set | ||
203 | the ``HAVE_TOUCHSCREEN`` variable equal to one as follows: | ||
204 | HAVE_TOUCHSCREEN=1 | ||
205 | |||
206 | **Q:** How do I make sure connected network interfaces are brought up by | ||
207 | default? | ||
208 | |||
209 | **A:** The default interfaces file provided by the netbase recipe does | ||
210 | not automatically bring up network interfaces. Therefore, you will need | ||
211 | to add a BSP-specific netbase that includes an interfaces file. See the | ||
212 | "`Miscellaneous BSP-Specific Recipe | ||
213 | Files <&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes>`__" section in | ||
214 | the Yocto Project Board Support Packages (BSP) Developer's Guide for | ||
215 | information on creating these types of miscellaneous recipe files. | ||
216 | |||
217 | For example, add the following files to your layer: | ||
218 | meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces | ||
219 | meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend | ||
220 | |||
221 | **Q:** How do I create images with more free space? | ||
222 | |||
223 | **A:** By default, the OpenEmbedded build system creates images that are | ||
224 | 1.3 times the size of the populated root filesystem. To affect the image | ||
225 | size, you need to set various configurations: | ||
226 | |||
227 | - *Image Size:* The OpenEmbedded build system uses the | ||
228 | ```IMAGE_ROOTFS_SIZE`` <#var-IMAGE_ROOTFS_SIZE>`__ variable to define | ||
229 | the size of the image in Kbytes. The build system determines the size | ||
230 | by taking into account the initial root filesystem size before any | ||
231 | modifications such as requested size for the image and any requested | ||
232 | additional free disk space to be added to the image. | ||
233 | |||
234 | - *Overhead:* Use the | ||
235 | ```IMAGE_OVERHEAD_FACTOR`` <#var-IMAGE_OVERHEAD_FACTOR>`__ variable | ||
236 | to define the multiplier that the build system applies to the initial | ||
237 | image size, which is 1.3 by default. | ||
238 | |||
239 | - *Additional Free Space:* Use the | ||
240 | ```IMAGE_ROOTFS_EXTRA_SPACE`` <#var-IMAGE_ROOTFS_EXTRA_SPACE>`__ | ||
241 | variable to add additional free space to the image. The build system | ||
242 | adds this space to the image after it determines its | ||
243 | ``IMAGE_ROOTFS_SIZE``. | ||
244 | |||
245 | **Q:** Why don't you support directories with spaces in the pathnames? | ||
246 | |||
247 | **A:** The Yocto Project team has tried to do this before but too many | ||
248 | of the tools the OpenEmbedded build system depends on, such as | ||
249 | ``autoconf``, break when they find spaces in pathnames. Until that | ||
250 | situation changes, the team will not support spaces in pathnames. | ||
251 | |||
252 | **Q:** How do I use an external toolchain? | ||
253 | |||
254 | **A:** The toolchain configuration is very flexible and customizable. It | ||
255 | is primarily controlled with the ``TCMODE`` variable. This variable | ||
256 | controls which ``tcmode-*.inc`` file to include from the | ||
257 | ``meta/conf/distro/include`` directory within the `Source | ||
258 | Directory <#source-directory>`__. | ||
259 | |||
260 | The default value of ``TCMODE`` is "default", which tells the | ||
261 | OpenEmbedded build system to use its internally built toolchain (i.e. | ||
262 | ``tcmode-default.inc``). However, other patterns are accepted. In | ||
263 | particular, "external-*" refers to external toolchains. One example is | ||
264 | the Sourcery G++ Toolchain. The support for this toolchain resides in | ||
265 | the separate ``meta-sourcery`` layer at | ||
266 | ` <http://github.com/MentorEmbedded/meta-sourcery/>`__. | ||
267 | |||
268 | In addition to the toolchain configuration, you also need a | ||
269 | corresponding toolchain recipe file. This recipe file needs to package | ||
270 | up any pre-built objects in the toolchain such as ``libgcc``, | ||
271 | ``libstdcc++``, any locales, and ``libc``. | ||
272 | |||
273 | **Q:** How does the OpenEmbedded build system obtain source code and | ||
274 | will it work behind my firewall or proxy server? | ||
275 | |||
276 | **A:** The way the build system obtains source code is highly | ||
277 | configurable. You can setup the build system to get source code in most | ||
278 | environments if HTTP transport is available. | ||
279 | |||
280 | When the build system searches for source code, it first tries the local | ||
281 | download directory. If that location fails, Poky tries | ||
282 | ```PREMIRRORS`` <#var-PREMIRRORS>`__, the upstream source, and then | ||
283 | ```MIRRORS`` <#var-MIRRORS>`__ in that order. | ||
284 | |||
285 | Assuming your distribution is "poky", the OpenEmbedded build system uses | ||
286 | the Yocto Project source ``PREMIRRORS`` by default for SCM-based | ||
287 | sources, upstreams for normal tarballs, and then falls back to a number | ||
288 | of other mirrors including the Yocto Project source mirror if those | ||
289 | fail. | ||
290 | |||
291 | As an example, you could add a specific server for the build system to | ||
292 | attempt before any others by adding something like the following to the | ||
293 | ``local.conf`` configuration file: PREMIRRORS_prepend = "\\ git://.*/.\* | ||
294 | http://www.yoctoproject.org/sources/ \\n \\ ftp://.*/.\* | ||
295 | http://www.yoctoproject.org/sources/ \\n \\ http://.*/.\* | ||
296 | http://www.yoctoproject.org/sources/ \\n \\ https://.*/.\* | ||
297 | http://www.yoctoproject.org/sources/ \\n" | ||
298 | |||
299 | These changes cause the build system to intercept Git, FTP, HTTP, and | ||
300 | HTTPS requests and direct them to the ``http://`` sources mirror. You | ||
301 | can use ``file://`` URLs to point to local directories or network shares | ||
302 | as well. | ||
303 | |||
304 | Aside from the previous technique, these options also exist: | ||
305 | BB_NO_NETWORK = "1" This statement tells BitBake to issue an error | ||
306 | instead of trying to access the Internet. This technique is useful if | ||
307 | you want to ensure code builds only from local sources. | ||
308 | |||
309 | Here is another technique: BB_FETCH_PREMIRRORONLY = "1" This statement | ||
310 | limits the build system to pulling source from the ``PREMIRRORS`` only. | ||
311 | Again, this technique is useful for reproducing builds. | ||
312 | |||
313 | Here is another technique: BB_GENERATE_MIRROR_TARBALLS = "1" This | ||
314 | statement tells the build system to generate mirror tarballs. This | ||
315 | technique is useful if you want to create a mirror server. If not, | ||
316 | however, the technique can simply waste time during the build. | ||
317 | |||
318 | Finally, consider an example where you are behind an HTTP-only firewall. | ||
319 | You could make the following changes to the ``local.conf`` configuration | ||
320 | file as long as the ``PREMIRRORS`` server is current: PREMIRRORS_prepend | ||
321 | = "\\ ftp://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ | ||
322 | http://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ https://.*/.\* | ||
323 | http://www.yoctoproject.org/sources/ \\n" BB_FETCH_PREMIRRORONLY = "1" | ||
324 | These changes would cause the build system to successfully fetch source | ||
325 | over HTTP and any network accesses to anything other than the | ||
326 | ``PREMIRRORS`` would fail. | ||
327 | |||
328 | The build system also honors the standard shell environment variables | ||
329 | ``http_proxy``, ``ftp_proxy``, ``https_proxy``, and ``all_proxy`` to | ||
330 | redirect requests through proxy servers. | ||
331 | |||
332 | .. note:: | ||
333 | |||
334 | You can find more information on the " | ||
335 | Working Behind a Network Proxy | ||
336 | " Wiki page. | ||
337 | |||
338 | **Q:** Can I get rid of build output so I can start over? | ||
339 | |||
340 | **A:** Yes - you can easily do this. When you use BitBake to build an | ||
341 | image, all the build output goes into the directory created when you run | ||
342 | the build environment setup script (i.e. | ||
343 | ````` <#structure-core-script>`__). By default, this `Build | ||
344 | Directory <#build-directory>`__ is named ``build`` but can be named | ||
345 | anything you want. | ||
346 | |||
347 | Within the Build Directory, is the ``tmp`` directory. To remove all the | ||
348 | build output yet preserve any source code or downloaded files from | ||
349 | previous builds, simply remove the ``tmp`` directory. | ||
350 | |||
351 | **Q:** Why do ``${bindir}`` and ``${libdir}`` have strange values for | ||
352 | ``-native`` recipes? | ||
353 | |||
354 | **A:** Executables and libraries might need to be used from a directory | ||
355 | other than the directory into which they were initially installed. | ||
356 | Complicating this situation is the fact that sometimes these executables | ||
357 | and libraries are compiled with the expectation of being run from that | ||
358 | initial installation target directory. If this is the case, moving them | ||
359 | causes problems. | ||
360 | |||
361 | This scenario is a fundamental problem for package maintainers of | ||
362 | mainstream Linux distributions as well as for the OpenEmbedded build | ||
363 | system. As such, a well-established solution exists. Makefiles, | ||
364 | Autotools configuration scripts, and other build systems are expected to | ||
365 | respect environment variables such as ``bindir``, ``libdir``, and | ||
366 | ``sysconfdir`` that indicate where executables, libraries, and data | ||
367 | reside when a program is actually run. They are also expected to respect | ||
368 | a ``DESTDIR`` environment variable, which is prepended to all the other | ||
369 | variables when the build system actually installs the files. It is | ||
370 | understood that the program does not actually run from within | ||
371 | ``DESTDIR``. | ||
372 | |||
373 | When the OpenEmbedded build system uses a recipe to build a | ||
374 | target-architecture program (i.e. one that is intended for inclusion on | ||
375 | the image being built), that program eventually runs from the root file | ||
376 | system of that image. Thus, the build system provides a value of | ||
377 | "/usr/bin" for ``bindir``, a value of "/usr/lib" for ``libdir``, and so | ||
378 | forth. | ||
379 | |||
380 | Meanwhile, ``DESTDIR`` is a path within the `Build | ||
381 | Directory <#build-directory>`__. However, when the recipe builds a | ||
382 | native program (i.e. one that is intended to run on the build machine), | ||
383 | that program is never installed directly to the build machine's root | ||
384 | file system. Consequently, the build system uses paths within the Build | ||
385 | Directory for ``DESTDIR``, ``bindir`` and related variables. To better | ||
386 | understand this, consider the following two paths where the first is | ||
387 | relatively normal and the second is not: | ||
388 | |||
389 | .. note:: | ||
390 | |||
391 | Due to these lengthy examples, the paths are artificially broken | ||
392 | across lines for readability. | ||
393 | |||
394 | /home/maxtothemax/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/ | ||
395 | 1.2.8-r0/sysroot-destdir/usr/bin | ||
396 | /home/maxtothemax/poky-bootchart2/build/tmp/work/x86_64-linux/ | ||
397 | zlib-native/1.2.8-r0/sysroot-destdir/home/maxtothemax/poky-bootchart2/ | ||
398 | build/tmp/sysroots/x86_64-linux/usr/bin Even if the paths look unusual, | ||
399 | they both are correct - the first for a target and the second for a | ||
400 | native recipe. These paths are a consequence of the ``DESTDIR`` | ||
401 | mechanism and while they appear strange, they are correct and in | ||
402 | practice very effective. | ||
403 | |||
404 | **Q:** The files provided by my ``*-native`` recipe do not appear to be | ||
405 | available to other recipes. Files are missing from the native sysroot, | ||
406 | my recipe is installing to the wrong place, or I am getting permissions | ||
407 | errors during the do_install task in my recipe! What is wrong? | ||
408 | |||
409 | **A:** This situation results when a build system does not recognize the | ||
410 | environment variables supplied to it by `BitBake <#bitbake-term>`__. The | ||
411 | incident that prompted this FAQ entry involved a Makefile that used an | ||
412 | environment variable named ``BINDIR`` instead of the more standard | ||
413 | variable ``bindir``. The makefile's hardcoded default value of | ||
414 | "/usr/bin" worked most of the time, but not for the recipe's ``-native`` | ||
415 | variant. For another example, permissions errors might be caused by a | ||
416 | Makefile that ignores ``DESTDIR`` or uses a different name for that | ||
417 | environment variable. Check the the build system to see if these kinds | ||
418 | of issues exist. | ||