path: root/documentation/ref-manual/ref-qa-checks.xml

<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >

<chapter id='ref-qa-checks'>
<title>QA Error and Warning Messages</title>

<section id='qa-introduction'>
    <title>Introduction</title>

    <para>
        Fixing QA issues in your recipes can take significant time and effort
        when writing new recipes.
        Sometimes you might be tempted to ignore a QA message or even to
        disable these QA checks.
        This chapter provides a list of the QA messages and brief explanations
        of the issues you could encounter so that you can properly resolve
        problems.
    </para>

    <para>
        The next section provides a list of all QA error and warning
        messages based on a default configuration.
        Each entry provides the message or error form along with an explanation.
        <note>
            <title>Notes</title>
            <itemizedlist>
                <listitem><para>
                    As mentioned, this list of error and warning messages is for
                    QA checks only.
                    The list does not cover all possible build errors or
                    warnings you could encounter.
                    </para></listitem>
                <listitem><para>
                    Because some QA checks are disabled by default, this list
                    does not include all possible QA check errors and warnings.
                    </para></listitem>
            </itemizedlist>
        </note>
    </para>
</section>

<section id='qa-errors-and-warnings'>
    <title>Errors and Warnings</title>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;packagename&gt;: &lt;path&gt; is using libexec please relocate to &lt;libexecdir&gt; [libexec]
                </literallayout>
                The specified package contains files in
                <filename>/usr/libexec</filename>.
                By default, <filename>libexecdir</filename> is set to
                "${libdir}/${BPN}" rather than to "/usr/libexec".
                Thus, installing to <filename>/usr/libexec</filename>
                is likely not desirable.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     package &lt;packagename&gt; contains bad RPATH &lt;rpath&gt; in file &lt;file&gt; [rpaths]
                </literallayout>
                The specified binary produced by the recipe contains dynamic
                library load paths (rpaths) that contain build system paths
                such as
                <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>,
                which could potentially be a security issue.
                Check for bad <filename>-rpath</filename> options being passed
                to the linker in your
                <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
                log.
                Depending on the build system used by the software being built,
                there might be a configure option to disable rpath usage
                completely within the build of the software.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;packagename&gt;: &lt;file&gt; contains probably-redundant RPATH &lt;rpath&gt; [useless-rpaths]
                </literallayout>
                The specified binary produced by the recipe contains dynamic
                library load paths (rpaths) that on a standard system are
                searched by default by the linker (e.g.
                <filename>/lib</filename> and <filename>/usr/lib</filename>).
                While these paths will not cause any breakage, they do waste
                space and are unnecessary.
                Depending on the build system used by the software being built,
                there might be a configure option to disable rpath usage
                completely within the build of the software.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     non -dev/-dbg/-nativesdk package contains symlink .so: &lt;packagename&gt; path '&lt;path&gt;' [dev-so]
                </literallayout>
                Symlink <filename>.so</filename> files are for development
                only, and should therefore go into the
                <filename>-dev</filename> package.
                This situation might occur if you add
                <filename>*.so*</filename> rather than
                <filename>*.so.*</filename> to a non-dev package.
                Change
                <link linkend='var-FILES'><filename>FILES</filename></link>
                (and possibly
                <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>)
                such that the specified <filename>.so</filename> file goes
                into an appropriate <filename>-dev</filename> package.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     non -staticdev package contains static .a library: &lt;packagename&gt; path '&lt;path&gt;' [staticdev]
                </literallayout>
                Static <filename>.a</filename> library files should go into
                a <filename>-staticdev</filename> package.
                Change
                <link linkend='var-FILES'><filename>FILES</filename></link>
                (and possibly
                <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>)
                such that the specified <filename>.a</filename> file goes into
                an appropriate <filename>-staticdev</filename> package.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;packagename&gt;: found library in wrong location [libdir]
                </literallayout>
                The specified file may have been installed into an incorrect
                (possibly hardcoded) installation path.
                For example, this test will catch recipes that install
                <filename>/lib/bar.so</filename> when
                <filename>${base_libdir}</filename> is "lib32".
                Another example is when recipes install
                <filename>/usr/lib64/foo.so</filename> when
                <filename>${libdir}</filename> is "/usr/lib".
                False positives occasionally exist.
                For these cases add "libdir" to
                <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>
                for the package.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     non debug package contains .debug directory: &lt;packagename&gt; path &lt;path&gt; [debug-files]
                </literallayout>
                The specified package contains a
                <filename>.debug</filename> directory, which should not appear
                in anything but the <filename>-dbg</filename> package.
                This situation might occur if you add a path which contains
                a <filename>.debug</filename> directory and do not explicitly
                add the <filename>.debug</filename> directory to the
                <filename>-dbg</filename> package.
                If this is the case, add the <filename>.debug</filename>
                directory explicitly to <filename>FILES_${PN}-dbg</filename>.
                See
                <link linkend='var-FILES'><filename>FILES</filename></link>
                for additional information on <filename>FILES</filename>.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     Architecture did not match (&lt;machine_arch&gt; to &lt;file_arch&gt;) on &lt;file&gt;
                </literallayout>
                By default, the OpenEmbedded build system checks the Executable
                and Linkable Format (ELF) type, bit size, and endianness of
                any binaries to ensure they match the target architecture.
                This test fails if any binaries do not match the type since
                there would be an incompatibility.
                The test could indicate that the wrong compiler or compiler
                options have been used.
                Sometimes software, like bootloaders, might need to bypass this
                check.
                If the file you receive the error for is firmware that is not
                intended to be executed within the target operating system
                or is intended to run on a separate processor within the
                device, you can add "arch" to
                <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>
                for the package.
                Another option is to check the
                <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
                log and verify that the
                compiler options being used are correct.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     Bit size did not match (&lt;machine_bits&gt; to &lt;file_bits&gt;) &lt;recipe&gt; on &lt;file&gt;
                </literallayout>
                By default, the OpenEmbedded build system checks the Executable
                and Linkable Format (ELF) type, bit size, and endianness of
                any binaries to ensure they match the target architecture.
                This test fails if any binaries do not match the type since
                there would be an incompatibility.
                The test could indicate that the wrong compiler or compiler
                options have been used.
                Sometimes software, like bootloaders, might need to bypass this
                check.
                If the file you receive the error for is firmware that is not
                intended to be executed within the target operating system
                or is intended to run on a separate processor within the
                device, you can add "arch" to
                <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>
                for the package.
                Another option is to check the
                <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
                log and verify that the
                compiler options being used are correct.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     Endianness did not match (&lt;machine_endianness&gt; to &lt;file_endianness&gt;) on &lt;file&gt; [arch]
                </literallayout>
                By default, the OpenEmbedded build system checks the Executable
                and Linkable Format (ELF) type, bit size, and endianness of
                any binaries to ensure they match the target architecture.
                This test fails if any binaries do not match the type since
                there would be an incompatibility.
                The test could indicate that the wrong compiler or compiler
                options have been used.
                Sometimes software, like bootloaders, might need to bypass this
                check.
                If the file you receive the error for is firmware that is not
                intended to be executed within the target operating system
                or is intended to run on a separate processor within the
                device, you can add "arch" to
                <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>
                for the package.
                Another option is to check the
                <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
                log and verify that the
                compiler options being used are correct.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     ELF binary '&lt;file&gt;' has relocations in .text [textrel]
                </literallayout>
                The specified ELF binary contains relocations in its
                <filename>.text</filename> sections.
                This situation can result in a performance impact at runtime.
                <note>
                    A bug currently exists that causes this warning to appear
                    erroneously.
                    See
                    <ulink url='https://bugzilla.yoctoproject.org/show_bug.cgi?id=6104'></ulink>
                    for more information.
                </note>
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     No GNU_HASH in the elf binary: '&lt;file&gt;' [ldflags]
                </literallayout>
                This indicates that binaries produced when building the
                recipe have not been linked with the
                <link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
                options provided by the build system.
                Check to be sure that the <filename>LDFLAGS</filename> variable
                is being passed to the linker command.
                A common workaround for this situation is to pass in
                <filename>LDFLAGS</filename> using
                <link linkend='var-TARGET_CC_ARCH'><filename>TARGET_CC_ARCH</filename></link>
                within the recipe as follows:
                <literallayout class='monospaced'>
     TARGET_CC_ARCH += "${LDFLAGS}"
                </literallayout>
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     Package &lt;packagename&gt; contains Xorg driver (&lt;driver&gt;) but no xorg-abi- dependencies [xorg-driver-abi]
                </literallayout>
                The specified package contains an Xorg driver, but does not
                have a corresponding ABI package dependency.
                The xserver-xorg recipe provides driver ABI names.
                All drivers should depend on the ABI versions that they have
                been built against.
                Driver recipes that include
                <filename>xorg-driver-input.inc</filename> or
                <filename>xorg-driver-video.inc</filename> will automatically
                get these versions.
                Consequently, you should only need to explicitly add
                dependencies to binary driver recipes.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     The /usr/share/info/dir file is not meant to be shipped in a particular package. [infodir]
                </literallayout>
                The <filename>/usr/share/info/dir</filename> should not be
                packaged.
                Add the following line to your
                <link linkend='ref-tasks-install'><filename>do_install</filename></link>
                task or to your <filename>do_install_append</filename> within
                the recipe as follows:
                <literallayout class='monospaced'>
     rm ${D}${infodir}/dir
                </literallayout>
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     Symlink &lt;path&gt; in &lt;packagename&gt; points to TMPDIR [symlink-to-sysroot]
                </literallayout>
                The specified symlink points into
                <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
                on the host.
                Such symlinks will work on the host.
                However, they are clearly invalid when running on the target.
                You should either correct the symlink to use a relative path
                or remove the symlink.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;file&gt; failed sanity test (workdir) in path &lt;path&gt; [la]
                </literallayout>
                The specified <filename>.la</filename> file contains
                <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
                paths.
                Any <filename>.la</filename> file containing these paths
                is incorrect since <filename>libtool</filename> adds the
                correct sysroot prefix when using the files automatically
                itself.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;file&gt; failed sanity test (tmpdir) in path &lt;path&gt; [pkgconfig]
                </literallayout>
                The specified <filename>.pc</filename> file contains
                <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link><filename>/</filename><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
                paths.
                Any <filename>.pc</filename> file containing these paths is
                incorrect since <filename>pkg-config</filename> itself adds
                the correct sysroot prefix when the files are accessed.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;packagename&gt; rdepends on &lt;debug_packagename&gt; [debug-deps]
                </literallayout>
                A dependency exists between the specified non-dbg package
                (a package whose name does not end in
                <filename>-dbg</filename>) and a package that is a
                <filename>dbg</filename> package.
                The <filename>dbg</filename> packages contain debug symbols
                and are usually brought in using the dbg-pkgs
                <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
                value or explicitly brought into the image using
                <link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
                (or as a dependency of another <filename>dbg</filename>
                package brought in using either method).
                The dependency might have been automatically added
                (because the <filename>dbg</filename> package erroneously
                contains files that it should not contain (e.g. a non-symlink
                <filename>.so</filename> file) or it might have been added
                manually (e.g. by adding to
                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;packagename&gt; rdepends on &lt;dev_packagename&gt; [dev-deps]
                </literallayout>
                A dependency exists between the specified non-dev package
                (a package whose name does not end in
                <filename>-dev</filename>) and a package that is a
                <filename>dev</filename> package.
                The <filename>dev</filename> packages contain development
                headers and are usually brought in using the dev-pkgs
                <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
                value or explicitly brought into the image using
                <link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
                (or as a dependency of another <filename>dev</filename>
                package brought in using either method).
                The dependency might have been automatically added (because
                the <filename>dev</filename> package erroneously contains
                files that it should not have (e.g. a non-symlink
                <filename>.so</filename> file) or it might have been added
                manually (e.g. by adding to
                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;var&gt;_&lt;packagename&gt; is invalid: &lt;comparison&gt; (&lt;value&gt;)   only comparisons &lt;, =, &gt;, &lt;=, and &gt;= are allowed [dep-cmp]
                </literallayout>
                If you are adding a versioned dependency relationship to one
                of the dependency variables
                (<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
                <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
                <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
                or
                <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>),
                you must only use the named comparison operators.
                Change the versioned dependency values you are adding to match
                those listed in the message.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;recipename&gt;: The compile log indicates that host include and/or library paths were used. Please check the log '&lt;logfile&gt;' for more information. [compile-host-path]
                </literallayout>
                The log for the
                <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
                task indicates that paths on the host were searched for files,
                which is not appropriate when cross-compiling.
                Look for "is unsafe for cross-compilation" or "CROSS COMPILE
                Badness" in the specified log file.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;recipename&gt;: The install log indicates that host include and/or library paths were used. Please check the log '&lt;logfile&gt;' for more information. [install-host-path]
                </literallayout>
                The log for the
                <link linkend='ref-tasks-install'><filename>do_install</filename></link>
                task indicates that paths on the host were searched for files,
                which is not appropriate when cross-compiling.
                Look for "is unsafe for cross-compilation" or "CROSS COMPILE
                Badness" in the specified log file.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     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 '&lt;path&gt;'
                </literallayout>
                The log for the
                <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
                task indicates that paths on the host were searched for files,
                which is not appropriate when cross-compiling.
                Look for "is unsafe for cross-compilation" or "CROSS COMPILE
                Badness" in the specified log file.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;packagename&gt; doesn't match the [a-z0-9.+-]+ regex [pkgname]
                </literallayout>
                The convention within the OpenEmbedded build system is for
                package names (sometimes enforced by the package manager itself)
                to require that package names are all lower case and to
                allow a restricted set of characters.
                If your recipe name does not match this, or you add packages
                to
                <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
                that do not conform to the convention, then you will receive
                this error.
                Rename your recipe.
                Or, if you have added a non-conforming package name to
                <filename>PACKAGES</filename>, change the package name
                appropriately.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;recipe&gt;: configure was passed unrecognized options: &lt;options&gt; [unknown-configure-option]
                </literallayout>
                The configure script is reporting that the specified options
                are unrecognized.
                This situation could be because the options were previously
                valid but have been removed.
                Or, there was a mistake when the options were added and there
                is another option that should be used instead.
                If you are unsure, consult the upstream build documentation,
                the <filename>./configure &dash;&dash;help</filename> output,
                and the upstream change log or release notes.
                Once you have worked out what the appropriate change is, you
                can update
                <link linkend='var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></link>
                or the individual
                <link linkend='var-PACKAGECONFIG'><filename>PACKAGECONFIG</filename></link>
                option values accordingly.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     Recipe &lt;recipefile&gt; has PN of "&lt;recipename&gt;" which is in OVERRIDES, this can result in unexpected behavior. [pn-overrides]
                </literallayout>
                The specified recipe has a name
                (<link linkend='var-PN'><filename>PN</filename></link>)
                value that appears in
                <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>.
                If a recipe is named such that its <filename>PN</filename>
                value matches something already in
                <filename>OVERRIDES</filename> (e.g. <filename>PN</filename>
                happens to be the same as
                <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
                or
                <link linkend='var-DISTRO'><filename>DISTRO</filename></link>),
                it can have unexpected consequences.
                For example, assignments such as
                <filename>FILES_${PN} = "xyz"</filename> effectively turn into
                <filename>FILES = "xyz"</filename>.
                Rename your recipe (or if <filename>PN</filename> is being
                set explicitly, change the <filename>PN</filename> value) so
                that the conflict does not occur.
                See
                <link linkend='var-FILES'><filename>FILES</filename></link>
                for additional information.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;recipefile&gt;: Variable &lt;variable&gt; is set as not being package specific, please fix this. [pkgvarcheck]
                </literallayout>
                Certain variables
                (<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
                <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
                <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
                <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
                <link linkend='var-FILES'><filename>FILES</filename></link>,
                <filename>pkg_preinst</filename>,
                <filename>pkg_postinst</filename>,
                <filename>pkg_prerm</filename>,
                <filename>pkg_postrm</filename>, and
                <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>)
                should always be set specific to a package (i.e. they should
                be set with a package name override such as
                <filename>RDEPENDS_${PN} = "value"</filename> rather than
                <filename>RDEPENDS = "value"</filename>).
                If you receive this error, correct any assignments to these
                variables within your recipe.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     File '&lt;file&gt;' from &lt;recipename&gt; was already stripped, this will prevent future debugging! [already-stripped]
                </literallayout>
                Produced binaries have already been stripped prior to the
                build system extracting debug symbols.
                It is common for upstream software projects to default to
                stripping debug symbols for output binaries.
                In order for debugging to work on the target using
                <filename>-dbg</filename> packages, this stripping must be
                disabled.
                Depending on the build system used by the software being built,
                disabling this stripping could be as easy as specifying an
                additional configure option.
                If not, disabling stripping might involve patching the build
                scripts.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;packagename&gt; is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list]
                </literallayout>
                Package names must appear only once in the
                <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
                variable.
                You might receive this error if you are attempting to add a
                package to <filename>PACKAGES</filename> that is
                already in the variable's value.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     FILES variable for package &lt;packagename&gt; contains '//' which is invalid. Attempting to fix this but you should correct the metadata. [files-invalid]
                </literallayout>
                The string "//" is invalid in a Unix path.
                Correct all occurrences where this string appears in a
                <link linkend='var-FILES'><filename>FILES</filename></link>
                variable so that there is only a single "/".
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
      &lt;recipename&gt;: Files/directories were installed but not shipped [installed-vs-shipped]
                </literallayout>
                Files have been installed within the
                <link linkend='ref-tasks-install'><filename>do_install</filename></link>
                task but have not been included in any package by way of the
                <link linkend='var-FILES'><filename>FILES</filename></link>
                variable.
                Files that do not appear in any package cannot be present in
                an image later on in the build process.
                You need to one of the following:
                <itemizedlist>
                    <listitem><para>
                        Add the files to <filename>FILES</filename> for the
                        package you want them to appear in (e.g.
                        <filename>FILES_${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename> for the main
                        package).
                        </para></listitem>
                    <listitem><para>
                        Delete the files at the end of the
                        <filename>do_install</filename> task if the files
                        are not needed in any package
                        </para></listitem>
                </itemizedlist>
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;oldpackage&gt;-&lt;oldpkgversion&gt; was registered as shlib provider for &lt;library&gt;, changing it to &lt;newpackage&gt;-&lt;newpkgversion&gt; because it was built later
                </literallayout>
                This message means that both
                <filename>&lt;oldpackage&gt;</filename> and
                <filename>&lt;newpackage&gt;</filename> provide the specified
                shared library.
                You can expect this message when a recipe has been renamed.
                However, if that is not the case, the message might indicate
                that a private version of a library is being erroneously
                picked up as the provider for a common library.
                If that is the case, you should add the library's
                <filename>.so</filename> file name to
                <link linkend='var-PRIVATE_LIBS'><filename>PRIVATE_LIBS</filename></link>
                in the recipe that provides
                the private version of the library.
                </para></listitem>
        </itemizedlist>
    </para>

<!--
Here are some messages that might be documented in the future.
Right now we are not documenting them because the QA checks are not
enabled by default:

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     Desktop file issue: &lt;error&gt; [desktop]
                </literallayout>
                NEED A DESCRIPTION AND SOLUTION
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;packagename&gt;: &lt;file&gt;, installed in the base_prefix, requires a shared library under exec_prefix (&lt;exec_prefix&t;g) [unsafe-references-in-binaries]
                </literallayout>
                NEED A DESCRIPTION AND SOLUTION
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        <itemizedlist>
            <listitem><para>
                <literallayout class='monospaced'>
     &lt;packagename&gt;: Found a reference to &lt;exec_prefix&gt;/ in &lt;path&gt; - Shell scripts in base_bindir and base_sbindir should not reference anything in exec_prefix [unsafe-references-in-scripts]
                </literallayout>
                NEED A DESCRIPTION AND SOLUTION
                </para></listitem>
        </itemizedlist>
    </para>
-->
</section>

</chapter>
<!--
vim: expandtab tw=80 ts=4
-->