c# this关键字扩展方法,验证数据

变量的概念

  返回  

9 QA 错误和警告消息.

2021/8/20 19:07:40 浏览:

9 QA 错误和警告消息

目录

9 QA 错误和警告消息

9.1简介

9.2错误和警告

9.3配置和禁用 QA 检查


9.1简介

构建配方时,OpenEmbedded 构建系统会对输出执行各种 QA 检查,以确保检测和报告常见问题。有时,当您创建一个新配方来构建新软件时,它会顺利构建。如果不是这种情况,或者当您在构建任何软件时遇到 QA 问题,可能需要一点时间来解决它们。

虽然忽略 QA 消息甚至禁用 QA 检查很诱人,但最好尝试解决任何报告的 QA 问题。本章提供了 QA 消息列表和您可能遇到的问题的简要说明,以便您可以正确解决问题。

下一部分提供了基于默认配置的所有 QA 错误和警告消息的列表。每个条目都提供消息或错误表单以及解释。

注意

  • 在每条消息的末尾,相关的 QA 测试的名称(如“ inane.bbclass ”部分中所列)出现在方括号内。

  • 如前所述,此错误和警告消息列表仅用于 QA 检查。该列表并未涵盖您可能遇到的所有可能的构建错误或警告。

  • 由于默认情况下禁用了某些 QA 检查,因此此列表不包括所有可能的 QA 检查错误和警告。

9.2错误和警告

  • <packagename>: <path> is using libexec please relocate to <libexecdir> [libexec]

    /usr/libexec当发行版配置使用不同的路径时,指定的包包含的文件<libexecdir>默认<libexecdir>$prefix/libexec. 但是,此默认值可以更改(例如${libdir})。

  • package <packagename> contains bad RPATH <rpath> in file <file> [rpaths]

    由配方生成的指定二进制文件包含动态库加载路径 (rpaths),其中包含构建系统路径,例如 TMPDIR,这对于目标来说是不正确的,并且可能是一个安全问题。-rpath 在do_compile日志中检查传递给链接器的错误选项 。根据正在构建的软件所使用的构建系统,可能有一个配置选项可以在软件构建中完全禁用 rpath 使用。

  • <packagename>: <file> contains probably-redundant RPATH <rpath> [useless-rpaths]

    由配方生成的指定二进制文件包含动态库加载路径(rpaths),默认情况下,链接器(例如/lib/usr/lib)会在标准系统上搜索这些路径。虽然这些路径不会造成任何破损,但它们确实浪费空间并且是不必要的。根据正在构建的软件所使用的构建系统,可能有一个配置选项可以在软件构建中完全禁用 rpath 使用。

  • <packagename> requires <files>, but no providers in its RDEPENDS [file-rdeps]

    已从指定文件上的指定包中识别出文件级依赖项,但RDEPENDS 中没有明确的对应条目。如果在运行时需要特定文件,则应在配方中声明RDEPENDS,以确保构建提供它们的包。

  • <packagename1> rdepends on <packagename2>, but it isn't a build dependency? [build-deps]

    两个指定的包之间存在运行时依赖关系,但配方中没有任何明确的内容来启用 OpenEmbedded 构建系统以确保满足依赖关系。这种情况通常由在打包阶段而不是预先添加的RDEPENDS值触发 ,这通常是基于包的内容自动进行的。在大多数情况下,您应该更改配方为依赖项添加显式RDEPENDS。

  • non -dev/-dbg/nativesdk- package contains symlink .so: <packagename> path '<path>' [dev-so]

    符号链接.so文件仅用于开发,因此应包含在-dev包中。如果您添加*.so*而不是添加*.so.*到非开发包,则可能会发生这种情况 。更改 FILES(可能还有 PACKAGES),以便指定的.so 文件进入适当的-dev包。

  • non -staticdev package contains static .a library: <packagename> path '<path>' [staticdev]

    静态.a库文件应该放在一个-staticdev包中。更改FILES(可能还有 PACKAGES),以便指定的.a文件进入适当的-staticdev包。

  • <packagename>: found library in wrong location [libdir]

    指定的文件可能已安装到错误的(可能是硬编码的)安装路径中。例如,此测试将捕获安装/lib/bar.so时间${base_libdir}为“lib32”的配方。另一个例子是当配方安装 /usr/lib64/foo.so${libdir}是“/usr/lib”。偶尔存在误报。对于这些情况,将“libdir”添加到 包的INSANE_SKIP。

  • non debug package contains .debug directory: <packagename> path <path> [debug-files]

    指定的包包含一个.debug目录,该目录不应出现在-dbg包之外的任何地方。如果您添加包含.debug目录的路径并且没有显式地将.debug目录添加到-dbg包中,则可能会发生这种情况。如果是这种情况,请将.debug目录显式添加到 FILES_${PN}-dbg. 有关FILES的其他信息,请参阅FILES。

  • Architecture did not match (<file_arch>, expected <machine_arch>) in <file> [arch]

    默认情况下,OpenEmbedded 构建系统会检查任何二进制文件的可执行和可链接格式 (ELF) 类型、位大小和字节序,以确保它们与目标架构匹配。如果任何二进制文件与类型不匹配,则此测试将失败,因为会存在不兼容性。该测试可能表明使用了错误的编译器或编译器选项。有时,软件(如引导加载程序)可能需要绕过此检查。如果您收到错误的文件是不打算在目标操作系统中执行或打算在设备内的单独处理器上运行的固件,您可以为包添加“arch”到 INSANE_SKIP。另一种选择是检查do_compile日志并验证所使用的编译器选项是否正确。

  • Bit size did not match (<file_bits>, expected <machine_bits>) in <file> [arch]

    默认情况下,OpenEmbedded 构建系统会检查任何二进制文件的可执行和可链接格式 (ELF) 类型、位大小和字节序,以确保它们与目标架构匹配。如果任何二进制文件与类型不匹配,则此测试将失败,因为会存在不兼容性。该测试可能表明使用了错误的编译器或编译器选项。有时,软件(如引导加载程序)可能需要绕过此检查。如果您收到错误的文件是不打算在目标操作系统中执行或打算在设备内的单独处理器上运行的固件,您可以为包添加“arch”到 INSANE_SKIP。另一种选择是检查do_compile日志并验证所使用的编译器选项是否正确。

  • Endianness did not match (<file_endianness>, expected <machine_endianness>) in <file> [arch]

    默认情况下,OpenEmbedded 构建系统会检查任何二进制文件的可执行和可链接格式 (ELF) 类型、位大小和字节序,以确保它们与目标架构匹配。如果任何二进制文件与类型不匹配,则此测试将失败,因为会存在不兼容性。该测试可能表明使用了错误的编译器或编译器选项。有时,软件(如引导加载程序)可能需要绕过此检查。如果您收到错误的文件是不打算在目标操作系统中执行或打算在设备内的单独处理器上运行的固件,您可以为包添加“arch”到 INSANE_SKIP。另一种选择是检查do_compile日志并验证所使用的编译器选项是否正确。

  • ELF binary '<file>' has relocations in .text [textrel]

    指定的 ELF 二进制文件在其.text 部分中包含重定位。这种情况可能会导致运行时的性能影响。

    通常,解决此性能问题的方法是在编译器命令行选项中添加“-fPIC”或“-fpic”。例如,给定在构建时读取CFLAGS 的软件,您可以将以下内容添加到您的配方中:

    CFLAGS:append = " -fPIC "
    

    有关运行时文本重定位的更多信息,请参阅 https://www.akkadia.org/drepper/textrelocs.html。

  • File '<file>' in package '<package>' doesn't have GNU_HASH (didn't pass LDFLAGS?) [ldflags]

    这表明构建配方时生成的二进制文件尚未与构建系统提供的LDFLAGS选项链接。检查以确保LDFLAGS 变量被传递给链接器命令。这种情况的常见解决方法是在配方中使用 TARGET_CC_ARCH传入LDFLAGS,如下所示:

    TARGET_CC_ARCH += "${LDFLAGS}"
    
  • Package <packagename> contains Xorg driver (<driver>) but no xorg-abi- dependencies [xorg-driver-abi]

    指定的包包含 Xorg 驱动程序,但没有相应的 ABI 包依赖项。xserver-xorg 配方提供驱动程序 ABI 名称。所有驱动程序都应依赖于构建它们的 ABI 版本。包含xorg-driver-input.incxorg-driver-video.inc将自动获取这些版本的驱动程序配方。因此,您应该只需要显式地向二进制驱动程序配方添加依赖项。

  • The /usr/share/info/dir file is not meant to be shipped in a particular package. [infodir]

    /usr/share/info/dir不应该被包装。将以下行添加到您的do_install任务或 do_install:append配方中,如下所示:

    rm ${D}${infodir}/dir
    
  • <file> failed sanity test (workdir) in path <path> [la]

    指定的.la文件包含TMPDIR 路径。任何.la包含这些路径的文件都是不正确的,因为 libtool在自动使用这些文件时会添加正确的 sysroot 前缀。

  • <file> failed sanity test (tmpdir) in path <path> [pkgconfig]

    指定的.pc文件包含 TMPDIR /WORKDIR 路径。任何.pc包含这些路径的文件都是不正确的,因为 pkg-config在访问这些文件时它会添加正确的 sysroot 前缀。

  • <packagename> rdepends on <debug_packagename> [debug-deps]

    指定的非 dbg 包(即名称不以 结尾-dbg的包)和作为包的包 之间存在依赖关系dbg。这些dbg包包含调试符号,并使用几种不同的方法引入:

    • 使用dbg-pkgs IMAGE_FEATURES值。

    • 使用IMAGE_INSTALL。

    • 作为dbg使用上述方法之一引入的另一个包的依赖项。

    依赖项可能是自动添加的,因为 dbg包错误地包含了它不应该包含的文件(例如非符号链接.so文件),或者它可能是手动添加的(例如通过添加到RDEPENDS)。

  • <packagename> rdepends on <dev_packagename> [dev-deps]

    指定的非开发包(名称不以 结尾-dev的包)和作为包的包之间存在依赖关系dev 。这些dev包包含开发头文件,通常使用几种不同的方法引入:

    • 使用dev-pkgs IMAGE_FEATURES值。

    • 使用IMAGE_INSTALL。

    • 作为dev使用上述方法之一引入的另一个包的依赖项。

    依赖项可能是自动添加的(因为 dev包错误地包含了它不应该包含的文件(例如非符号链接.so文件),或者它可能是手动添加的(例如通过添加到RDEPENDS)。

  • <var>:<packagename> is invalid: <comparison> (<value>)   only comparisons <, =, >, <=, and >= are allowed [dep-cmp]

    如果要将版本化依赖关系添加到依赖变量之一(RDEPENDS、 RRECOMMENDS、 RSUGGESTS、 RPROVIDES、 RREPLACES或 RCONFLICTS),则必须仅使用命名的比较运算符。更改您要添加的版本化依赖项值以匹配消息中列出的值。

  • <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]

    do_compile任务的日志表明在主机上的路径中搜索了文件,这在交叉编译时不合适。在指定的日志文件中查找“交叉编译不安全”或“CROSS COMPILE Badness”。

  • <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]

    do_install任务的日志表明在主机上的路径中搜索了文件,这在交叉编译时不合适。在指定的日志文件中查找“交叉编译不安全”或“CROSS COMPILE Badness”。

  • This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. [configure-unsafe]

    do_configure任务的日志表明在主机上的路径中搜索了文件,这在交叉编译时不合适。在指定的日志文件中查找“交叉编译不安全”或“CROSS COMPILE Badness”。

  • <packagename> doesn't match the [a-z0-9.+-]+ regex [pkgname]

    OpenEmbedded 构建系统中的约定(有时由包管理器本身强制执行)是要求包名称全部小写并允许使用有限的字符集。如果您的配方名称与此不匹配,或者您将不符合约定的包添加到 PACKAGES,那么您将收到此错误。重命名您的食谱。或者,如果您在PACKAGES 中添加了不符合标准的包名称,请适当更改包名称。

  • <recipe>: configure was passed unrecognized options: <options> [unknown-configure-option]

    配置脚本报告无法识别指定的选项。这种情况可能是因为这些选项以前是有效的,但已从配置脚本中删除。或者,添加选项时出错,应使用另一个选项。如果您不确定,请查阅上游构建文档、输出以及上游更改日志或发行说明。一旦您确定了适当的更改是什么,您可以相应地更新 EXTRA_OECONF、 PACKAGECONFIG_CONFARGS或各个PACKAGECONFIG选项值。./configure --help

  • Recipe <recipefile> has PN of "<recipename>" which is in OVERRIDES, this can result in unexpected behavior. [pn-overrides]

    指定的配方具有出现在OVERRIDES 中的名称 ( PN ) 值。如果一个配方被命名为它的PN值与OVERRIDES 中已经存在的东西相匹配 (例如PN恰好与MACHINE 或DISTRO相同),它可能会产生意想不到的后果。例如,诸如 有效地转换为. 重命名您的配方(或者如果PN被明确设置,则更改 PN值)以免发生冲突。有关其他信息,请参阅 文件。FILES_${PN} = "xyz"FILES = "xyz"

  • <recipefile>: Variable <variable> is set as not being package specific, please fix this. [pkgvarcheck]

    某些变量(RDEPENDS、 RRECOMMENDS、 RSUGGESTS、 RCONFLICTS、 RPROVIDES、 RREPLACES、FILES、 pkg_preinstpkg_postinstpkg_prermpkg_postrm和 ALLOW_EMPTY)应始终设置为特定于包(即它们应设置为包名称覆盖,例如而不是 )。如果您收到此错误,请更正配方中对这些变量的任何分配。RDEPENDS:${PN} = "value"RDEPENDS = "value"

  • recipe uses DEPENDS:${PN}, should use DEPENDS [pkgvarcheck]

    此检查查找DEPENDS:${PN} 错误的设置实例(DEPENDS是一个配方范围的变量,因此为特定包指定它是不正确的,这样的分配也不会实际工作。)改为设置DEPENDS。

  • File '<file>' from <recipename> was already stripped, this will prevent future debugging! [already-stripped]

    在构建系统提取调试符号之前,生成的二进制文件已经被剥离。上游软件项目通常默认剥离输出二进制文件的调试符号。为了使用-dbg包在目标上进行调试,必须禁用此剥离。

    根据正在构建的软件所使用的构建系统,禁用此剥离可能就像指定额外的配置选项一样简单。如果没有,禁用剥离可能涉及修补构建脚本。在后一种情况下,查找对“strip”或“STRIP”的引用,或者在链接器命令行上指定的“-s”或“-S”命令行选项(如果前面带有“ -Wl,”)。

    注意

    在这里禁用剥离并不意味着最终打包的二进制文件将不被剥离。一旦 OpenEmbedded 构建系统将调试符号拆分到-dbg包中,它就会从二进制文件中剥离这些符号。

  • <packagename> is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list]

    包名称在PACKAGES变量中只能出现一次 。如果您尝试向PACKAGES添加一个已经在变量值中的包,您可能会收到此错误。

  • FILES variable for package <packagename> contains '//' which is invalid. Attempting to fix this but you should correct the metadata. [files-invalid]

    字符串“//”在 Unix 路径中无效。更正此字符串出现在FILES变量中的所有事件,以便只有一个“/”。

  • <recipename>: Files/directories were installed but not shipped in any package [installed-vs-shipped]

    文件已安装在 do_install任务中,但尚未通过FILES 变量包含在任何包中。未出现在任何包中的文件不能出现在稍后的构建过程中的映像中。您需要执行以下操作之一:

    • 将文件添加到FILES为你想让他们出现在(例如包FILES:${PN}主包)。

    • do_install如果任何包中不需要这些文件,请在任务结束时删除这些文件。

  • <oldpackage>-<oldpkgversion> was registered as shlib provider for <library>, changing it to <newpackage>-<newpkgversion> because it was built later

    此消息的装置,这两个<oldpackage><newpackage> 提供指定的共享库。当配方已重命名时,您会看到此消息。但是,如果情况并非如此,则该消息可能表明某个库的私有版本被错误地选择为公共库的提供者。如果是这种情况,您应该将库的.so文件名添加到 提供库私有版本的配方中的PRIVATE_LIBS中。

  • LICENSE:<packagename> includes licenses (<licenses>) that are not listed in LICENSE [unlisted-pkg-lics]

    配方的许可证应该是此配方生成的所有软件包的所有许可证的超集。换句话说,任何 license inLICENSE:*也应该出现在 LICENSE 中。

  • AM_GNU_GETTEXT used but no inherit gettext [configure-gettext]

    如果配方正在构建使用 automake 的东西并且 automake 文件包含一个AM_GNU_GETTEXT指令,那么如果配方中没有确保 gettext 在构建期间可用的语句,则此检查将失败。添加以删除警告。inherit gettextinherit gettext

  • package contains mime types but does not inherit mime: <packagename> path '<file>' [mime]

    指定的包包含 mime 类型文件(.xmlfiles in ${datadir}/mime/packages),但不继承 mime 类,这将确保这些文件得到正确安装。如果不需要,请添加到配方或删除步骤中的文件 。inherit mimedo_install

  • package contains desktop file with key 'MimeType' but does not inhert mime-xdg: <packagename> path '<file>' [mime-xdg]

    指定的包包含一个带有“MimeType”键的 .desktop 文件,但不继承激活它所需的 mime-xdg 类。如果不需要,请添加到配方或删除步骤中的文件。inherit mimedo_install

  • <recipename>: SRC_URI uses unstable GitHub archives [src-uri-bad]

    GitHub 提供了“归档”压缩包,但是这些压缩包可以即时重新生成,因此文件的签名不一定与 SRC_URI 校验和中的签名匹配,从而导致构建失败。建议您使用官方发布的 tarball 或切换到实际 git 存储库中的相应修订版本。

  • SRC_URI uses PN not BPN [src-uri-bad]

    如果SRC_URI 的某些部分需要引用菜谱名称,则应该使用 ${ BPN } 而不是 ${ PN } 这样做,因为后者会因相同菜谱的不同变体而改变,例如当使用BBCLASSEXTEND 或 multilib时。如果${PN} 在SRC_URI值中找到对的引用,则此检查将失败- 将其${BPN}改为。

  • <recipename>: recipe doesn't inherit features_check [unhandled-features-check]

    此检查确保如果使用features_check 类支持的变量之一(例如REQUIRED_DISTRO_FEATURES),则配方继承features_check以便要求实际工作。如果您看到此消息,请添加到您的配方中,或者在不需要时删除对变量的引用。inherit features_check

  • <recipename>: recipe defines ALTERNATIVE:<packagename> but doesn't inherit update-alternatives. This might fail during do_rootfs later! [missing-update-alternatives]

    此检查可确保如果配方设置了ALTERNATIVE变量,则该配方也继承了update-alternatives,以便正确设置替代品。如果您看到此消息,请添加到您的配方中,或者在不需要时删除对变量的引用。inherit update-alternatives

  • <packagename>: <file> maximum shebang size exceeded, the maximum size is 128. [shebang-size]

    此检查可确保#!脚本的 shebang 行(在第一行中)不超过 128 个字符,这可能会在运行时导致错误,具体取决于操作系统。如果您看到此消息,则可能需要修补指定的脚本以使其更短,以避免运行时出现问题。

  • <packagename> contains perllocal.pod (<files>), should not be installed [perllocalpod]

    perllocal.pod是本地安装模块的索引文件,因此不应由任何分发包安装。在CPAN类已设置NO_PERLLOCAL阻止大多数的Perl食谱生成此文件,但如果一个配方使用MakeMaker直接那么他们可能无法正确执行此操作。此检查确保 perllocal.pod 不在任何包中,以避免多个包传送此文件,因此如果安装在一起,它们的包会发生冲突。

  • <packagename> package is not obeying usrmerge distro feature. /<path> should be relocated to /usr. [usrmerge]

    如果usrmerge在DISTRO_FEATURES 中,此检查将确保没有包将文件安装到根 ( /bin/sbin/lib/lib64) 目录。如果您看到这条消息,则表明do_install步(或者构建过程 do_install被调用到,如使用硬编码路径,而不是就此成立(变量,等等),并应使之变确实。make installbindirsbindir

  • Fuzz detected: <patch output> [patch-fuzz]

    do_patch 任务中应用补丁时,此检查会寻找“模糊”的证据。补丁模糊是patch工具忽略某些上下文行以应用补丁的情况。考虑这个例子:

    要应用的补丁:

    --- filename
    +++ filename
     context line 1
     context line 2
     context line 3
    +newly added line
     context line 4
     context line 5
     context line 6
    

    原始源代码:

    different context line 1
    different context line 2
    context line 3
    context line 4
    different context line 5
    different context line 6
    

    结果(使用模糊补丁后):

    different context line 1
    different context line 2
    context line 3
    newly added line
    context line 4
    different context line 5
    different context line 6
    

    很有可能,新添加的行实际上是添加到了一个完全错误的位置,或者它已经在原始源中并且是第二次添加的。如果上下文第 3 行和第 4 行为空白或其中只有通用内容(例如#endif或 ),则这尤其可能}。根据打补丁的代码,打错补丁的文件完全有可能仍然编译而不会出错。

    如何消除补丁模糊警告

    使用devtool警告中说明的命令。首先,将源代码解压到 devtool 工作区中:

    devtool modify <recipe>
    

    这将应用所有补丁,并在工作区中创建新的提交 - 更新补丁上下文。

    然后,替换配方层中的补丁:

    devtool finish --force-patch-refresh <recipe> <layer_path>
    

    然后需要审查补丁更新(最好使用并行差异工具)以确保它们确实在做正确的事情,即:

    1. 它们应用于文件中的正确位置;

    2. 它们不会引入重复的行,或以其他方式做不再需要的事情。

    要确认这些事情,您还可以查看 devtool 工作区中的修补源代码,通常在 <build_dir>/workspace/sources/<recipe>/

    审核完成后,您可以创建和发布图层提交,其中包含修改上下文的补丁更新。Devtool 也可能会刷新补丁中的其他内容,这些内容可以丢弃。

9.3配置和禁用 QA 检查

您可以全局配置 QA 检查,以便特定检查失败 分别使用WARN_QA和ERROR_QA变量引发警告或错误消息 。您还可以使用INSANE_SKIP禁用特定配方中的检查。有关如何使用 QA 检查的信息,请参阅“ crazy.bbclass ”部分。

注意

请记住,QA 检查旨在检测打包输出中的实际或潜在问题。所以在禁用这些检查时要小心。

联系我们

如果您对我们的服务有兴趣,请及时和我们联系!

服务热线:18288888888
座机:18288888888
传真:
邮箱:888888@qq.com
地址:郑州市文化路红专路93号