Yocto：创建一个新的交叉编译器供其他食谱使用答案

【问题标题】：Yocto: Creating a New Cross Compiler for use by Other RecipesYocto：创建一个新的交叉编译器供其他食谱使用
【发布时间】：2021-02-24 20:37:50
【问题描述】：

问题

在构建期间创建供其他配方使用的新的非 gcc 交叉编译器的适当方法是什么？

注意：这是专门关于在构建期间使用的交叉编译器，不用于由populate_sdk 任务创建的 SDK。欢迎提供有关 SDK 生成的其他信息，但不是问题的重点。

背景

我正在尝试将专有软件框架集成到 yocto 构建中。出于法律原因（NDA），我不能谈论框架的细节，但是我希望这个过程对于为另一个架构生成代码的任何其他专有工具都是相同的。以真正的程序员方式，让我们将此框架称为foo。富有想象力，我知道。

到目前为止，我已经创建了一个用于构建交叉编译器本身的方法（为了简洁和 NDA 合规性而进行了修剪）：

foo-cross.bb

inherit cross

DEPENDS = ""

do_configure () { ... }

do_compile () { ... }

do_install () {
    install -d ${D}${libdir}/foo
    cp -r ./outdir/* ${D}${libdir}/foo
}

这个方法有效，因为我可以cd 进入构建目录并手动运行二进制文件以按预期执行操作。万岁！

接下来，我为依赖此框架和附带编译器的应用程序创建了一个新的 BitBake 类（如前所述）：

foo.bbclass

DEPENDS += "foo-cross"

# Do not inherit GCC and libc; this is handled by foo-cross
INHIBIT_DEFAULT_DEPS = "1"

do_compile() {
    ...
}
do_compile[depends] += "foo-cross:do_populate_sysroot"

fakeroot do_install { ... }
do_install[depends] += "virtual/fakeroot-native:do_populate_sysroot"

有了这个，任何配方都应该能够inherit foo 并参加比赛。

问题

主要问题是使用此方案会导致recipe-sysroot-native 无法填充foo-cross 的已安装内容，显然会导致编译失败。我确实看到 testapp/1.0-r0/recipe-sysroot-native/installeddeps/foo-cross 已创建，但 recipe-sysroot-native/${libdir}/foo 中仍然没有。

在一个相关问题中，我收到一条警告消息，我认为这是我所看到问题的真正根源：

WARNING: testapp-1.0-r0 do_prepare_recipe_sysroot: Manifest /build/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-foo-cross.populate_sysroot not found in raspberrypi4 armv7vet2hf-neon-vfpv4 armv7vehf-neon-vfpv4 armv7vet2hf-neon armv7vehf-neon armv7vet2hf-vfp armv7vehf-vfp armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk (variant '')?

这对我来说尤其莫名其妙，但在某种程度上解释了文件丢失的原因。这引发了一些问题：

鉴于我的主机是 x86_64（第一部分），但我的构建目标是基于 ARM 的平台，为什么清单声明为 x86_64_x86_64-nativesdk？
鉴于我只继承了cross，-nativesdk 部分从何而来？
x86_64_x86_64-nativesdk是在目标列表中，为什么找不到？

我没有列出我试图解决这个错误的所有事情（我在这个问题上工作的时间比我愿意承认的要长），我从头开始回到我的问题：什么是设置用于 Yocto 的新的非 gcc 交叉编译器？

【问题讨论】：

为什么需要另一个交叉编译器？这是为了构建将包含在 rootfs 中的某种类型的裸机固件吗？一种处理方法是为新的交叉编译器设置一台机器，以便您可以构建固件，然后使用 multiconfig 构建固件并在一次 bitbake 运行中将其包含在 rootfs 中。
我的工资等级已经决定使用这个框架，所以我被这个烂摊子困住了。不幸的是，对于 POSIX，该框架捆绑了一个破解版的 clang + mono，并且不允许对这个内部编译器进行任何配置。唯一支持的“官方”构建是通过 Visual Studio。他们确实提供了一组 CLI 工具，但总体支持很差。关于固件：这实际上是为了构建一个 Linux 二进制文件，所以它应该可以通过 Yocto 实现。正如我上面提到的，我有命令独立完成所有这些工作；我只是无法让 yocto 正确填充 sysroot。

标签： cross-compiling yocto bitbake openembedded

【解决方案1】：

TL;DR

将以下内容添加到foo-cross.bb：

PN = "foo-cross-${TUNE_PKGARCH}"
PROVIDES = "foo-cross"

等等，什么？

Yocto 在确定准确给定配方的行为方式时使用了许多信息源。这包括显而易见的内容，例如 include 或 inherit 指令、显式变量设置和配方名称本身的确切格式 (${PN})。

这是我的问题的最后一个条件。您可以在 Yocto 文档中找到几个地方提到特定的配方命名，例如：

以这种方式创建配方时，配方名称必须遵循此命名>约定：
myrecipe-native.bb
               
不使用此命名约定可能会导致由依赖于该命名约定的现有代码引起的微妙问题。

来自Yocto Mega Manual。

奇怪的是，cross.bbclass 和 staging.bbclass 的文档中都没有提到这颗智慧之珠。例如，如果您查看 Poky 的 gcc-cross.bb 或 go-cross.bb 食谱，您可能会怀疑只需添加 -cross 就足够了。你会错的。要了解原因，请考虑来自staging.bbclass 的以下 sn-p（实际文件；不是文档）：

native = False
if c.endswith("-native") or "-cross-" in c or "-crosssdk" in c:
    native = True

你看到了吗？再看一遍。用于匹配跨工具链配方的标识符是-cross-。注意尾随连字符。如果您像我在上面所做的那样假设您将拥有一个继承 cross 的交叉编译器配方，但 not 在暂存期间被声明为本机配方。嘘。

幸运的是，这可以通过上面的 TL;DR 解决。首先，我们将${PN} 重新定义为foo-cross-${TUNE_ARCH}。这会导致上述情况和另一个（埋在poky/meta/lib/oe/sstatesig.py）正确解决。其次，我们定义了PROVIDES，这样我们仍然可以依赖foo-cross，而不是完全限定的名称，在我的例子中，它很长。

备注

上述分析是在 Yocto 3.1 上执行的，可能会在未来的修订版中发生变化。
如果给定的配方只能针对某些架构构建，它仍然可以依赖于foo-cross-longnamehere，视用例而定。
如果您长时间盯着staging.bbclass 的来源，您会看到一艘帆船。

【讨论】：