diff options
Diffstat (limited to 'documentation/ref-manual/ref-qa-checks.rst')
-rw-r--r-- | documentation/ref-manual/ref-qa-checks.rst | 524 |
1 files changed, 524 insertions, 0 deletions
diff --git a/documentation/ref-manual/ref-qa-checks.rst b/documentation/ref-manual/ref-qa-checks.rst new file mode 100644 index 0000000000..a8b9ef60e4 --- /dev/null +++ b/documentation/ref-manual/ref-qa-checks.rst | |||
@@ -0,0 +1,524 @@ | |||
1 | ***************************** | ||
2 | QA Error and Warning Messages | ||
3 | ***************************** | ||
4 | |||
5 | .. _qa-introduction: | ||
6 | |||
7 | Introduction | ||
8 | ============ | ||
9 | |||
10 | When building a recipe, the OpenEmbedded build system performs various | ||
11 | QA checks on the output to ensure that common issues are detected and | ||
12 | reported. Sometimes when you create a new recipe to build new software, | ||
13 | it will build with no problems. When this is not the case, or when you | ||
14 | have QA issues building any software, it could take a little time to | ||
15 | resolve them. | ||
16 | |||
17 | While it is tempting to ignore a QA message or even to disable QA | ||
18 | checks, it is best to try and resolve any reported QA issues. This | ||
19 | chapter provides a list of the QA messages and brief explanations of the | ||
20 | issues you could encounter so that you can properly resolve problems. | ||
21 | |||
22 | The next section provides a list of all QA error and warning messages | ||
23 | based on a default configuration. Each entry provides the message or | ||
24 | error form along with an explanation. | ||
25 | |||
26 | .. note:: | ||
27 | |||
28 | - At the end of each message, the name of the associated QA test (as | ||
29 | listed in the "```insane.bbclass`` <#ref-classes-insane>`__" | ||
30 | section) appears within square brackets. | ||
31 | |||
32 | - As mentioned, this list of error and warning messages is for QA | ||
33 | checks only. The list does not cover all possible build errors or | ||
34 | warnings you could encounter. | ||
35 | |||
36 | - Because some QA checks are disabled by default, this list does not | ||
37 | include all possible QA check errors and warnings. | ||
38 | |||
39 | .. _qa-errors-and-warnings: | ||
40 | |||
41 | Errors and Warnings | ||
42 | =================== | ||
43 | |||
44 | - ``<packagename>: <path> is using libexec please relocate to <libexecdir> [libexec]`` | ||
45 | |||
46 | The specified package contains files in ``/usr/libexec`` when the | ||
47 | distro configuration uses a different path for ``<libexecdir>`` By | ||
48 | default, ``<libexecdir>`` is ``$prefix/libexec``. However, this | ||
49 | default can be changed (e.g. ``${libdir}``). | ||
50 | |||
51 | |||
52 | |||
53 | - ``package <packagename> contains bad RPATH <rpath> in file <file> [rpaths]`` | ||
54 | |||
55 | The specified binary produced by the recipe contains dynamic library | ||
56 | load paths (rpaths) that contain build system paths such as | ||
57 | ```TMPDIR`` <#var-TMPDIR>`__, which are incorrect for the target and | ||
58 | could potentially be a security issue. Check for bad ``-rpath`` | ||
59 | options being passed to the linker in your | ||
60 | ```do_compile`` <#ref-tasks-compile>`__ log. Depending on the build | ||
61 | system used by the software being built, there might be a configure | ||
62 | option to disable rpath usage completely within the build of the | ||
63 | software. | ||
64 | |||
65 | |||
66 | |||
67 | - ``<packagename>: <file> contains probably-redundant RPATH <rpath> [useless-rpaths]`` | ||
68 | |||
69 | The specified binary produced by the recipe contains dynamic library | ||
70 | load paths (rpaths) that on a standard system are searched by default | ||
71 | by the linker (e.g. ``/lib`` and ``/usr/lib``). While these paths | ||
72 | will not cause any breakage, they do waste space and are unnecessary. | ||
73 | Depending on the build system used by the software being built, there | ||
74 | might be a configure option to disable rpath usage completely within | ||
75 | the build of the software. | ||
76 | |||
77 | |||
78 | |||
79 | - ``<packagename> requires <files>, but no providers in its RDEPENDS [file-rdeps]`` | ||
80 | |||
81 | A file-level dependency has been identified from the specified | ||
82 | package on the specified files, but there is no explicit | ||
83 | corresponding entry in ```RDEPENDS`` <#var-RDEPENDS>`__. If | ||
84 | particular files are required at runtime then ``RDEPENDS`` should be | ||
85 | declared in the recipe to ensure the packages providing them are | ||
86 | built. | ||
87 | |||
88 | |||
89 | |||
90 | - ``<packagename1> rdepends on <packagename2>, but it isn't a build dependency? [build-deps]`` | ||
91 | |||
92 | A runtime dependency exists between the two specified packages, but | ||
93 | there is nothing explicit within the recipe to enable the | ||
94 | OpenEmbedded build system to ensure that dependency is satisfied. | ||
95 | This condition is usually triggered by an | ||
96 | ```RDEPENDS`` <#var-RDEPENDS>`__ value being added at the packaging | ||
97 | stage rather than up front, which is usually automatic based on the | ||
98 | contents of the package. In most cases, you should change the recipe | ||
99 | to add an explicit ``RDEPENDS`` for the dependency. | ||
100 | |||
101 | |||
102 | |||
103 | - ``non -dev/-dbg/nativesdk- package contains symlink .so: <packagename> path '<path>' [dev-so]`` | ||
104 | |||
105 | Symlink ``.so`` files are for development only, and should therefore | ||
106 | go into the ``-dev`` package. This situation might occur if you add | ||
107 | ``*.so*`` rather than ``*.so.*`` to a non-dev package. Change | ||
108 | ```FILES`` <#var-FILES>`__ (and possibly | ||
109 | ```PACKAGES`` <#var-PACKAGES>`__) such that the specified ``.so`` | ||
110 | file goes into an appropriate ``-dev`` package. | ||
111 | |||
112 | |||
113 | |||
114 | - ``non -staticdev package contains static .a library: <packagename> path '<path>' [staticdev]`` | ||
115 | |||
116 | Static ``.a`` library files should go into a ``-staticdev`` package. | ||
117 | Change ```FILES`` <#var-FILES>`__ (and possibly | ||
118 | ```PACKAGES`` <#var-PACKAGES>`__) such that the specified ``.a`` file | ||
119 | goes into an appropriate ``-staticdev`` package. | ||
120 | |||
121 | |||
122 | |||
123 | - ``<packagename>: found library in wrong location [libdir]`` | ||
124 | |||
125 | The specified file may have been installed into an incorrect | ||
126 | (possibly hardcoded) installation path. For example, this test will | ||
127 | catch recipes that install ``/lib/bar.so`` when ``${base_libdir}`` is | ||
128 | "lib32". Another example is when recipes install | ||
129 | ``/usr/lib64/foo.so`` when ``${libdir}`` is "/usr/lib". False | ||
130 | positives occasionally exist. For these cases add "libdir" to | ||
131 | ```INSANE_SKIP`` <#var-INSANE_SKIP>`__ for the package. | ||
132 | |||
133 | |||
134 | |||
135 | - ``non debug package contains .debug directory: <packagename> path <path> [debug-files]`` | ||
136 | |||
137 | The specified package contains a ``.debug`` directory, which should | ||
138 | not appear in anything but the ``-dbg`` package. This situation might | ||
139 | occur if you add a path which contains a ``.debug`` directory and do | ||
140 | not explicitly add the ``.debug`` directory to the ``-dbg`` package. | ||
141 | If this is the case, add the ``.debug`` directory explicitly to | ||
142 | ``FILES_${PN}-dbg``. See ```FILES`` <#var-FILES>`__ for additional | ||
143 | information on ``FILES``. | ||
144 | |||
145 | |||
146 | |||
147 | - ``Architecture did not match (<machine_arch> to <file_arch>) on <file> [arch]`` | ||
148 | |||
149 | By default, the OpenEmbedded build system checks the Executable and | ||
150 | Linkable Format (ELF) type, bit size, and endianness of any binaries | ||
151 | to ensure they match the target architecture. This test fails if any | ||
152 | binaries do not match the type since there would be an | ||
153 | incompatibility. The test could indicate that the wrong compiler or | ||
154 | compiler options have been used. Sometimes software, like | ||
155 | bootloaders, might need to bypass this check. If the file you receive | ||
156 | the error for is firmware that is not intended to be executed within | ||
157 | the target operating system or is intended to run on a separate | ||
158 | processor within the device, you can add "arch" to | ||
159 | ```INSANE_SKIP`` <#var-INSANE_SKIP>`__ for the package. Another | ||
160 | option is to check the ```do_compile`` <#ref-tasks-compile>`__ log | ||
161 | and verify that the compiler options being used are correct. | ||
162 | |||
163 | |||
164 | |||
165 | - ``Bit size did not match (<machine_bits> to <file_bits>) <recipe> on <file> [arch]`` | ||
166 | |||
167 | By default, the OpenEmbedded build system checks the Executable and | ||
168 | Linkable Format (ELF) type, bit size, and endianness of any binaries | ||
169 | to ensure they match the target architecture. This test fails if any | ||
170 | binaries do not match the type since there would be an | ||
171 | incompatibility. The test could indicate that the wrong compiler or | ||
172 | compiler options have been used. Sometimes software, like | ||
173 | bootloaders, might need to bypass this check. If the file you receive | ||
174 | the error for is firmware that is not intended to be executed within | ||
175 | the target operating system or is intended to run on a separate | ||
176 | processor within the device, you can add "arch" to | ||
177 | ```INSANE_SKIP`` <#var-INSANE_SKIP>`__ for the package. Another | ||
178 | option is to check the ```do_compile`` <#ref-tasks-compile>`__ log | ||
179 | and verify that the compiler options being used are correct. | ||
180 | |||
181 | |||
182 | |||
183 | - ``Endianness did not match (<machine_endianness> to <file_endianness>) on <file> [arch]`` | ||
184 | |||
185 | By default, the OpenEmbedded build system checks the Executable and | ||
186 | Linkable Format (ELF) type, bit size, and endianness of any binaries | ||
187 | to ensure they match the target architecture. This test fails if any | ||
188 | binaries do not match the type since there would be an | ||
189 | incompatibility. The test could indicate that the wrong compiler or | ||
190 | compiler options have been used. Sometimes software, like | ||
191 | bootloaders, might need to bypass this check. If the file you receive | ||
192 | the error for is firmware that is not intended to be executed within | ||
193 | the target operating system or is intended to run on a separate | ||
194 | processor within the device, you can add "arch" to | ||
195 | ```INSANE_SKIP`` <#var-INSANE_SKIP>`__ for the package. Another | ||
196 | option is to check the ```do_compile`` <#ref-tasks-compile>`__ log | ||
197 | and verify that the compiler options being used are correct. | ||
198 | |||
199 | |||
200 | |||
201 | - ``ELF binary '<file>' has relocations in .text [textrel]`` | ||
202 | |||
203 | The specified ELF binary contains relocations in its ``.text`` | ||
204 | sections. This situation can result in a performance impact at | ||
205 | runtime. | ||
206 | |||
207 | Typically, the way to solve this performance issue is to add "-fPIC" | ||
208 | or "-fpic" to the compiler command-line options. For example, given | ||
209 | software that reads ```CFLAGS`` <#var-CFLAGS>`__ when you build it, | ||
210 | you could add the following to your recipe: CFLAGS_append = " -fPIC " | ||
211 | |||
212 | For more information on text relocations at runtime, see | ||
213 | ` <http://www.akkadia.org/drepper/textrelocs.html>`__. | ||
214 | |||
215 | |||
216 | |||
217 | - ``No GNU_HASH in the elf binary: '<file>' [ldflags]`` | ||
218 | |||
219 | This indicates that binaries produced when building the recipe have | ||
220 | not been linked with the ```LDFLAGS`` <#var-LDFLAGS>`__ options | ||
221 | provided by the build system. Check to be sure that the ``LDFLAGS`` | ||
222 | variable is being passed to the linker command. A common workaround | ||
223 | for this situation is to pass in ``LDFLAGS`` using | ||
224 | ```TARGET_CC_ARCH`` <#var-TARGET_CC_ARCH>`__ within the recipe as | ||
225 | follows: TARGET_CC_ARCH += "${LDFLAGS}" | ||
226 | |||
227 | |||
228 | |||
229 | - ``Package <packagename> contains Xorg driver (<driver>) but no xorg-abi- dependencies [xorg-driver-abi]`` | ||
230 | |||
231 | The specified package contains an Xorg driver, but does not have a | ||
232 | corresponding ABI package dependency. The xserver-xorg recipe | ||
233 | provides driver ABI names. All drivers should depend on the ABI | ||
234 | versions that they have been built against. Driver recipes that | ||
235 | include ``xorg-driver-input.inc`` or ``xorg-driver-video.inc`` will | ||
236 | automatically get these versions. Consequently, you should only need | ||
237 | to explicitly add dependencies to binary driver recipes. | ||
238 | |||
239 | |||
240 | |||
241 | - ``The /usr/share/info/dir file is not meant to be shipped in a particular package. [infodir]`` | ||
242 | |||
243 | The ``/usr/share/info/dir`` should not be packaged. Add the following | ||
244 | line to your ```do_install`` <#ref-tasks-install>`__ task or to your | ||
245 | ``do_install_append`` within the recipe as follows: rm | ||
246 | ${D}${infodir}/dir | ||
247 | |||
248 | |||
249 | |||
250 | - ``Symlink <path> in <packagename> points to TMPDIR [symlink-to-sysroot]`` | ||
251 | |||
252 | The specified symlink points into ```TMPDIR`` <#var-TMPDIR>`__ on the | ||
253 | host. Such symlinks will work on the host. However, they are clearly | ||
254 | invalid when running on the target. You should either correct the | ||
255 | symlink to use a relative path or remove the symlink. | ||
256 | |||
257 | |||
258 | |||
259 | - ``<file> failed sanity test (workdir) in path <path> [la]`` | ||
260 | |||
261 | The specified ``.la`` file contains ```TMPDIR`` <#var-TMPDIR>`__ | ||
262 | paths. Any ``.la`` file containing these paths is incorrect since | ||
263 | ``libtool`` adds the correct sysroot prefix when using the files | ||
264 | automatically itself. | ||
265 | |||
266 | |||
267 | |||
268 | - ``<file> failed sanity test (tmpdir) in path <path> [pkgconfig]`` | ||
269 | |||
270 | The specified ``.pc`` file contains | ||
271 | ```TMPDIR`` <#var-TMPDIR>`__\ ``/``\ ```WORKDIR`` <#var-WORKDIR>`__ | ||
272 | paths. Any ``.pc`` file containing these paths is incorrect since | ||
273 | ``pkg-config`` itself adds the correct sysroot prefix when the files | ||
274 | are accessed. | ||
275 | |||
276 | |||
277 | |||
278 | - ``<packagename> rdepends on <debug_packagename> [debug-deps]`` | ||
279 | |||
280 | A dependency exists between the specified non-dbg package (i.e. a | ||
281 | package whose name does not end in ``-dbg``) and a package that is a | ||
282 | ``dbg`` package. The ``dbg`` packages contain debug symbols and are | ||
283 | brought in using several different methods: | ||
284 | |||
285 | - Using the ``dbg-pkgs`` | ||
286 | ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__ value. | ||
287 | |||
288 | - Using ```IMAGE_INSTALL`` <#var-IMAGE_INSTALL>`__. | ||
289 | |||
290 | - As a dependency of another ``dbg`` package that was brought in | ||
291 | using one of the above methods. | ||
292 | |||
293 | The dependency might have been automatically added because the | ||
294 | ``dbg`` package erroneously contains files that it should not contain | ||
295 | (e.g. a non-symlink ``.so`` file) or it might have been added | ||
296 | manually (e.g. by adding to ```RDEPENDS`` <#var-RDEPENDS>`__). | ||
297 | |||
298 | |||
299 | |||
300 | - ``<packagename> rdepends on <dev_packagename> [dev-deps]`` | ||
301 | |||
302 | A dependency exists between the specified non-dev package (a package | ||
303 | whose name does not end in ``-dev``) and a package that is a ``dev`` | ||
304 | package. The ``dev`` packages contain development headers and are | ||
305 | usually brought in using several different methods: | ||
306 | |||
307 | - Using the ``dev-pkgs`` | ||
308 | ```IMAGE_FEATURES`` <#var-IMAGE_FEATURES>`__ value. | ||
309 | |||
310 | - Using ```IMAGE_INSTALL`` <#var-IMAGE_INSTALL>`__. | ||
311 | |||
312 | - As a dependency of another ``dev`` package that was brought in | ||
313 | using one of the above methods. | ||
314 | |||
315 | The dependency might have been automatically added (because the | ||
316 | ``dev`` package erroneously contains files that it should not have | ||
317 | (e.g. a non-symlink ``.so`` file) or it might have been added | ||
318 | manually (e.g. by adding to ```RDEPENDS`` <#var-RDEPENDS>`__). | ||
319 | |||
320 | |||
321 | |||
322 | - ``<var>_<packagename> is invalid: <comparison> (<value>) only comparisons <, =, >, <=, and >= are allowed [dep-cmp]`` | ||
323 | |||
324 | If you are adding a versioned dependency relationship to one of the | ||
325 | dependency variables (```RDEPENDS`` <#var-RDEPENDS>`__, | ||
326 | ```RRECOMMENDS`` <#var-RRECOMMENDS>`__, | ||
327 | ```RSUGGESTS`` <#var-RSUGGESTS>`__, | ||
328 | ```RPROVIDES`` <#var-RPROVIDES>`__, | ||
329 | ```RREPLACES`` <#var-RREPLACES>`__, or | ||
330 | ```RCONFLICTS`` <#var-RCONFLICTS>`__), you must only use the named | ||
331 | comparison operators. Change the versioned dependency values you are | ||
332 | adding to match those listed in the message. | ||
333 | |||
334 | |||
335 | |||
336 | - ``<recipename>: The compile log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [compile-host-path]`` | ||
337 | |||
338 | The log for the ```do_compile`` <#ref-tasks-compile>`__ task | ||
339 | indicates that paths on the host were searched for files, which is | ||
340 | not appropriate when cross-compiling. Look for "is unsafe for | ||
341 | cross-compilation" or "CROSS COMPILE Badness" in the specified log | ||
342 | file. | ||
343 | |||
344 | |||
345 | |||
346 | - ``<recipename>: The install log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [install-host-path]`` | ||
347 | |||
348 | The log for the ```do_install`` <#ref-tasks-install>`__ task | ||
349 | indicates that paths on the host were searched for files, which is | ||
350 | not appropriate when cross-compiling. Look for "is unsafe for | ||
351 | cross-compilation" or "CROSS COMPILE Badness" in the specified log | ||
352 | file. | ||
353 | |||
354 | |||
355 | |||
356 | - ``This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. The path was '<path>'`` | ||
357 | |||
358 | The log for the ```do_configure`` <#ref-tasks-configure>`__ task | ||
359 | indicates that paths on the host were searched for files, which is | ||
360 | not appropriate when cross-compiling. Look for "is unsafe for | ||
361 | cross-compilation" or "CROSS COMPILE Badness" in the specified log | ||
362 | file. | ||
363 | |||
364 | |||
365 | |||
366 | - ``<packagename> doesn't match the [a-z0-9.+-]+ regex [pkgname]`` | ||
367 | |||
368 | The convention within the OpenEmbedded build system (sometimes | ||
369 | enforced by the package manager itself) is to require that package | ||
370 | names are all lower case and to allow a restricted set of characters. | ||
371 | If your recipe name does not match this, or you add packages to | ||
372 | ```PACKAGES`` <#var-PACKAGES>`__ that do not conform to the | ||
373 | convention, then you will receive this error. Rename your recipe. Or, | ||
374 | if you have added a non-conforming package name to ``PACKAGES``, | ||
375 | change the package name appropriately. | ||
376 | |||
377 | |||
378 | |||
379 | - ``<recipe>: configure was passed unrecognized options: <options> [unknown-configure-option]`` | ||
380 | |||
381 | The configure script is reporting that the specified options are | ||
382 | unrecognized. This situation could be because the options were | ||
383 | previously valid but have been removed from the configure script. Or, | ||
384 | there was a mistake when the options were added and there is another | ||
385 | option that should be used instead. If you are unsure, consult the | ||
386 | upstream build documentation, the ``./configure --help`` output, and | ||
387 | the upstream change log or release notes. Once you have worked out | ||
388 | what the appropriate change is, you can update | ||
389 | ```EXTRA_OECONF`` <#var-EXTRA_OECONF>`__, | ||
390 | ```PACKAGECONFIG_CONFARGS`` <#var-PACKAGECONFIG_CONFARGS>`__, or the | ||
391 | individual ```PACKAGECONFIG`` <#var-PACKAGECONFIG>`__ option values | ||
392 | accordingly. | ||
393 | |||
394 | |||
395 | |||
396 | - ``Recipe <recipefile> has PN of "<recipename>" which is in OVERRIDES, this can result in unexpected behavior. [pn-overrides]`` | ||
397 | |||
398 | The specified recipe has a name (```PN`` <#var-PN>`__) value that | ||
399 | appears in ```OVERRIDES`` <#var-OVERRIDES>`__. If a recipe is named | ||
400 | such that its ``PN`` value matches something already in ``OVERRIDES`` | ||
401 | (e.g. ``PN`` happens to be the same as ```MACHINE`` <#var-MACHINE>`__ | ||
402 | or ```DISTRO`` <#var-DISTRO>`__), it can have unexpected | ||
403 | consequences. For example, assignments such as | ||
404 | ``FILES_${PN} = "xyz"`` effectively turn into ``FILES = "xyz"``. | ||
405 | Rename your recipe (or if ``PN`` is being set explicitly, change the | ||
406 | ``PN`` value) so that the conflict does not occur. See | ||
407 | ```FILES`` <#var-FILES>`__ for additional information. | ||
408 | |||
409 | |||
410 | |||
411 | - ``<recipefile>: Variable <variable> is set as not being package specific, please fix this. [pkgvarcheck]`` | ||
412 | |||
413 | Certain variables (```RDEPENDS`` <#var-RDEPENDS>`__, | ||
414 | ```RRECOMMENDS`` <#var-RRECOMMENDS>`__, | ||
415 | ```RSUGGESTS`` <#var-RSUGGESTS>`__, | ||
416 | ```RCONFLICTS`` <#var-RCONFLICTS>`__, | ||
417 | ```RPROVIDES`` <#var-RPROVIDES>`__, | ||
418 | ```RREPLACES`` <#var-RREPLACES>`__, ```FILES`` <#var-FILES>`__, | ||
419 | ``pkg_preinst``, ``pkg_postinst``, ``pkg_prerm``, ``pkg_postrm``, and | ||
420 | ```ALLOW_EMPTY`` <#var-ALLOW_EMPTY>`__) should always be set specific | ||
421 | to a package (i.e. they should be set with a package name override | ||
422 | such as ``RDEPENDS_${PN} = "value"`` rather than | ||
423 | ``RDEPENDS = "value"``). If you receive this error, correct any | ||
424 | assignments to these variables within your recipe. | ||
425 | |||
426 | |||
427 | |||
428 | - ``File '<file>' from <recipename> was already stripped, this will prevent future debugging! [already-stripped]`` | ||
429 | |||
430 | Produced binaries have already been stripped prior to the build | ||
431 | system extracting debug symbols. It is common for upstream software | ||
432 | projects to default to stripping debug symbols for output binaries. | ||
433 | In order for debugging to work on the target using ``-dbg`` packages, | ||
434 | this stripping must be disabled. | ||
435 | |||
436 | Depending on the build system used by the software being built, | ||
437 | disabling this stripping could be as easy as specifying an additional | ||
438 | configure option. If not, disabling stripping might involve patching | ||
439 | the build scripts. In the latter case, look for references to "strip" | ||
440 | or "STRIP", or the "-s" or "-S" command-line options being specified | ||
441 | on the linker command line (possibly through the compiler command | ||
442 | line if preceded with "-Wl,"). | ||
443 | |||
444 | .. note:: | ||
445 | |||
446 | Disabling stripping here does not mean that the final packaged | ||
447 | binaries will be unstripped. Once the OpenEmbedded build system | ||
448 | splits out debug symbols to the | ||
449 | -dbg | ||
450 | package, it will then strip the symbols from the binaries. | ||
451 | |||
452 | |||
453 | |||
454 | - ``<packagename> is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list]`` | ||
455 | |||
456 | Package names must appear only once in the | ||
457 | ```PACKAGES`` <#var-PACKAGES>`__ variable. You might receive this | ||
458 | error if you are attempting to add a package to ``PACKAGES`` that is | ||
459 | already in the variable's value. | ||
460 | |||
461 | |||
462 | |||
463 | - ``FILES variable for package <packagename> contains '//' which is invalid. Attempting to fix this but you should correct the metadata. [files-invalid]`` | ||
464 | |||
465 | The string "//" is invalid in a Unix path. Correct all occurrences | ||
466 | where this string appears in a ```FILES`` <#var-FILES>`__ variable so | ||
467 | that there is only a single "/". | ||
468 | |||
469 | |||
470 | |||
471 | - ``<recipename>: Files/directories were installed but not shipped in any package [installed-vs-shipped]`` | ||
472 | |||
473 | Files have been installed within the | ||
474 | ```do_install`` <#ref-tasks-install>`__ task but have not been | ||
475 | included in any package by way of the ```FILES`` <#var-FILES>`__ | ||
476 | variable. Files that do not appear in any package cannot be present | ||
477 | in an image later on in the build process. You need to do one of the | ||
478 | following: | ||
479 | |||
480 | - Add the files to ``FILES`` for the package you want them to appear | ||
481 | in (e.g. ``FILES_${``\ ```PN`` <#var-PN>`__\ ``}`` for the main | ||
482 | package). | ||
483 | |||
484 | - Delete the files at the end of the ``do_install`` task if the | ||
485 | files are not needed in any package. | ||
486 | |||
487 | |||
488 | |||
489 | - ``<oldpackage>-<oldpkgversion> was registered as shlib provider for <library>, changing it to <newpackage>-<newpkgversion> because it was built later`` | ||
490 | |||
491 | This message means that both ``<oldpackage>`` and ``<newpackage>`` | ||
492 | provide the specified shared library. You can expect this message | ||
493 | when a recipe has been renamed. However, if that is not the case, the | ||
494 | message might indicate that a private version of a library is being | ||
495 | erroneously picked up as the provider for a common library. If that | ||
496 | is the case, you should add the library's ``.so`` file name to | ||
497 | ```PRIVATE_LIBS`` <#var-PRIVATE_LIBS>`__ in the recipe that provides | ||
498 | the private version of the library. | ||
499 | |||
500 | - ``LICENSE_<packagename> includes licenses (<licenses>) that are not listed in LICENSE [unlisted-pkg-lics]`` | ||
501 | |||
502 | The ```LICENSE`` <#var-LICENSE>`__ of the recipe should be a superset | ||
503 | of all the licenses of all packages produced by this recipe. In other | ||
504 | words, any license in ``LICENSE_*`` should also appear in | ||
505 | ```LICENSE`` <#var-LICENSE>`__. | ||
506 | |||
507 | |||
508 | |||
509 | Configuring and Disabling QA Checks | ||
510 | =================================== | ||
511 | |||
512 | You can configure the QA checks globally so that specific check failures | ||
513 | either raise a warning or an error message, using the | ||
514 | ```WARN_QA`` <#var-WARN_QA>`__ and ```ERROR_QA`` <#var-ERROR_QA>`__ | ||
515 | variables, respectively. You can also disable checks within a particular | ||
516 | recipe using ```INSANE_SKIP`` <#var-INSANE_SKIP>`__. For information on | ||
517 | how to work with the QA checks, see the | ||
518 | "```insane.bbclass`` <#ref-classes-insane>`__" section. | ||
519 | |||
520 | .. note:: | ||
521 | |||
522 | Please keep in mind that the QA checks exist in order to detect real | ||
523 | or potential problems in the packaged output. So exercise caution | ||
524 | when disabling these checks. | ||