将第三方组件添加到 Yocto/OpenEmbedded Linux - 从基础原理开始

在 Yocto/OpenEmbedded 中为不同目标交叉编译项目最直接的方法是利用 autotools。

 

支持 autotools 的项目提供了一组模板文件，然后由 autotools 使用这些文件生成 Makefiles 和相关的配置文件，这些文件适合为目标环境构建。

 

一个非常基本的“Hello World”风格的示例项目，名为 bbexample，已经提交到 GitHub 这里。

 

如果您查看这两个源文件 bbexample.c 和 bbexamplelib.c，您可以看到主入口点打印一个 Hello World 消息，然后调用共享库导出的一个函数，该函数也打印一条消息。

 

autotools 模板配置的讨论超出了本指南的范围，但 bbexample 项目基于可在 此处 找到的“快速而肮脏”示例。

 

项目本身构建了一个可执行文件 bbexample，它依赖于共享库 libbbexample.so。

 

要在独立于 Yocto 的主机上构建项目，首先克隆示例仓库

  $ mkdir ~/host 
  $ cd ~/host 
  $ git clone https://github.com/DynamicDevices/bbexample 

然后运行 autotools，配置构建，并生成项目

  $ cd bbexample 
  $ ./autogen.sh 
  $ ./configure
  $ make 

成功编译后，您将在构建文件夹的根目录中看到许多新文件。

 

有一个新的可执行文件 bbexample，它依赖于共享库 .libs/libbbexample.so。

 

由于此项目已在主机上构建并运行，您可以输入

  $ ./bbexample 

它将输出

  Hello Yocto World...
  Hello World (from a shared library!) 

因此，您现在已经证明您可以在主机上成功获取、配置和构建项目。

接下来，我们将研究 Yocto 如何自动化获取、配置和构建的过程，然后还安装和打包输出文件。

向构建系统添加新配方

有不同的方法可以向 Yocto 添加新配方。

一种方法是简单地在 Yocto 使用的现有层中的 recipe-foo/recipe 文件夹中创建一个新的 recipe_version.bb 文件。

将配方放置在现有层中（仅示例）

例如，您可以

  $ cd ~/yocto/poky-jethro-14.0.0/meta-yocto
  $ mkdir recipes-example
  $ cd recipes-example
  $ mkdir bbexample
  $ cd bbexample
  $ wget https://raw.githubusercontent.com/DynamicDevices/meta-example/master/recipes-example/bbexample/bbexample_1.0.bb

然后，配方将被 bitbake 拾取，您可以使用以下命令构建配方：

  $ cd ~/yocto/poky-jethro-14.0.0/build-qemux86
  $ bitbake bbexample 

使用新层管理配方

将配方添加到构建环境的首选方法，也是您应遵循本指南使用的方法，是将其放置在新层中。

层根据机器、功能或类似条件隔离特定的构建元数据集合，并有助于保持环境整洁。

一个名为 meta-example 的示例层已使用 yocto-layer 命令创建并提交到 GitHub 仓库 这里。

要使用这样的新层，您首先克隆 git 仓库，然后将该层添加到您的 bitbake 配置中，路径为 conf/bblayers.conf。

  $ cd ~/yocto/poky-jethro-14.0.0
  $ git clone https://github.com/DynamicDevices/meta-example
  $ cd ~/yocto/poky-jethro-14.0.0/build_qemux86
  $ nano conf/bblayers.conf

您的 bblayers.conf 应该类似于这样

  # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
  # changes incompatibly
  LCONF_VERSION = "6"
  BBPATH = "${TOPDIR}"
  BBFILES ?= ""
  BBLAYERS ?= " \
    /home/user/yocto/poky-jethro-14.0.0/meta \
    /home/user/yocto/poky-jethro-14.0.0/meta-yocto \
    /home/user/yocto/poky-jethro-14.0.0/meta-yocto-bsp \
    "
  BBLAYERS_NON_REMOVABLE ?= " \
    /home/user/yocto/poky-jethro-14.0.0/meta \
    /home/user/yocto/poky-jethro-14.0.0/meta-yocto \
    "

通过在 BBLAYERS 中添加一行，使新层对 bitbake 可见

  BBLAYERS ?= " \
    /home/user/yocto/poky-jethro-14.0.0/meta \
    /home/user/yocto/poky-jethro-14.0.0/meta-yocto \
    /home/user/yocto/poky-jethro-14.0.0/meta-yocto-bsp \
    /home/user/yocto/poky-jethro-14.0.0/meta-example \
    " 

现在 bitbake 可以看到新层中的配方了。

您还会看到当 bitbake 运行时并显示构建配置时，会显示您层的仓库分支和哈希值，这非常有用，尤其是在与他人比较构建失败原因时，例如：

  Build Configuration:
  BB_VERSION        = "1.22.0"
  BUILD_SYS         = "i686-linux"
  NATIVELSBSTRING   = "Ubuntu-12.04"
  TARGET_SYS        = "i586-poky-linux"
  MACHINE           = "qemux86"
  DISTRO            = "poky"
  DISTRO_VERSION    = "1.6"
  TUNE_FEATURES     = "m32 i586"
  TARGET_FPU        = ""
  meta
  meta-yocto
  meta-yocto-bsp    = "<unknown>:<unknown>" 
  meta-example      = "master:5ee4f20b041bc886b1d2d913ac11814057317634" 

基于 Git 仓库提交构建示例包

bbexample 配方

我们将要构建的配方是 /home/user/yocto/poky-jethro-14.0.0/meta-example/recipes-example/bbexample/bbexample_1.0.bb。

主要注意事项是

 

• SRC_URI 设置为指向 git 仓库
• SRC_REV 对应于该仓库中的特定提交（也可以指定分支）
• 定义了一个 LICENSE 变量以向构建环境（MIT）指示许可证类型，以及另一个变量，
• LIC_FILES_CHKSUM 指向源树中的一个或多个文件，这些文件将被检索，并附带相应的 md5 校验和，以确保有人实际验证了源许可证文件与提供给构建环境的许可证文件相符。此外，还确保该文件（以及可能存在的许可证）没有随时间变化。
• 配方构建的源目录 ${S} 设置为 "${WORKDIR}/git"，这是检索到的 git 仓库将被检出和解包的默认位置。
• 我们继承了一个名为 autotools 的类，它提供了功能，使 <code>bitbake</code> 能够自动构建支持 autotools 的项目。
• 这里明显缺少 do_install 函数，您可能在其他地方见过，因为这已由 autotools 支持处理

 

开始构建

  $ bitbake bbexample 

Bitbake 将执行一系列任务，包括从 git 仓库获取源、解包、配置、编译、安装和打包输出。

由于我们正在为模拟器 qemux86 构建，并且正在构建 RPM 包（默认），输出包将位于

~/yocto/poky-jethro-14.0.0/build_qemux86/tmp/deploy/rpm/i586/bbexample-1.0-r0.0.i586.rpm

对于其他机器目标，文件夹和后缀 i586 将替换为不同的机器特定名称。要查找包的位置，您可以使用

  $ cd ~/yocto/poky-jethro-14.0.0/build_qemux86/tmp/deploy/rpm
  $ find -name bbexample*

（或者，用您正在构建的配方名称的前缀代替 bbexample）

这将向您显示主软件包和 bitbake 为每个配方构建的辅助软件包，例如 -dev、-debug、-staticdev 等等。有关更多信息，请参见此处。

找到软件包后，您可以使用以下命令检查其内容是否符合预期：

  $ cd ~/yocto/poky-jethro-14.0.0/build_qemux86/tmp/deploy/rpm
  $ rpm -qlp i586/bbexample-1.0-r0.0.i586.rpm 

对于 bbexample 配方，我们期望看到交叉编译的可执行文件 bbexample 及其所需的共享库 libbbexample.so.1。

  /usr 
  /usr/bin
  /usr/bin/bbexample
  /usr/lib
  /usr/lib/libbbexample.so.1
  /usr/lib/libbbexample.so.1.0.0

然后，您可以将此配方的输出添加到您的输出镜像中，方法是将类似以下内容添加到您的 conf/local.conf 中

  IMAGE_INSTALL_append = " bbexample" 

或者，您可以使用 Yocto 的 package-management 工具（例如 smart）使新软件包对现有目标系统可用。

如果您希望在模拟器上构建并测试您的示例，请跳至 [[#在目标上测试示例]]

基于远程源存档构建示例包

我们将要构建的配方是 /home/user/yocto/poky-jethro-14.0.0/meta-example/recipes-example/bbexample/bbexample-rt_1.0.bb。

这基于之前从 git 检出构建的配方，主要区别在于我们正在从远程 tarball 构建。

这个 tarball 理论上可以包含我们希望构建的任何源代码，尽管有时构建失败可能需要修补源代码，并且如果未提供 autotools，则配方可能需要通过 do_install 函数进行扩展，以确保安装了适当的文件，并修改 FILES_${PN} 变量以确保安装的文件正确打包。

我们正在使用手动上传到 GitHub 的发布存档。该存档对应于标记为 v1.0 的 bbexample 源代码。这是优于使用动态生成的 GitHub 存档的首选方法，因为这些存档的校验和在重新生成时可能会间歇性地更改。手动上传的存档不会更改。

这个带标签的存档就是我们在配方 SRC_URI 中设置的用于检索和构建的内容。

主要注意事项是

 

• SRC_URI 设置为指向远程源存档

SRC_URI = "https://github.com/DynamicDevices/bbexample/releases/download/v1.0/bbexample-${PV}.tar.gz" 

 

理想情况下，我们将同时使用变量 ${PN} 和 ${PV}，它们将被替换为配方名称和配方版本，并且通常可以预期与源存档文件采用的命名约定相对应。这使得配方更通用，并且通过重命名配方 .bb 文件更容易更新到新版本的源代码。但是，由于我使用的是稍微不同的配方名称 bbexample-rt，我在此处硬编码了名称。

 

• 这里没有 SRC_REV，但我们有 SRC_URI 的 md5sum 和 sha256sum 校验和值。正如您所料，这些对应于在整个存档上运行这些算法时生成的特定校验和。

• 您可以通过自己检索文件，运行 md5sum archivename 和 sha256sum archivename 来手动生成这些文件，但是更容易出错地设置这些值，然后让 bitbake 检索存档并在校验和不正确时报错，此时它会告诉您正确的值应该是什么。例如：

 

SRC_URI[md5sum] = "e15723f0d5ac710bbe788cd3a797bc44"
SRC_URI[sha256sum] = "0b34eb133596348bb6f1a3ef5e05e4d5bf0c88062256affe768d8337d7cc8f83"

 

• 您应该注意，有时维护者会以相同的名称但内容更新的方式重新发布存档。如果发生这种情况，校验和检查将失败，您将需要调查这是否是因为下载损坏（检查 ~/yocto/poky-jethro-14.0.0/build_qemux86/downloads 中的下载存档）或者存档是否确实已更改。

• 定义了一个 LICENSE 变量以向构建环境（MIT）指示许可证类型，以及另一个变量，
• LIC_FILES_CHKSUM，指向源树中的一个文件，该文件将被检索，并附带相应的 md5 校验和，以确保有人实际验证了源许可证文件与提供给构建环境的许可证文件相符。此外，还确保该文件（以及可能存在的许可证）没有随时间变化。
• 配方构建的源目录 ${S} 设置为 S = "${WORKDIR}/bbexample-${PV}，这对应于从上传到 GitHub 的存档中提取源代码后的路径。

 

  # Make sure our source directory (for the build) matches the directory structure in the tarball
  S = "${WORKDIR}/bbexample-${PV}" 

 

• 我们继承了一个名为 autotools 的类，它提供了功能，使 bitbake 能够自动构建支持 autotools 的项目。
• 这里明显缺少 do_install 函数，您可能在其他地方见过，因为这已由 autotools 支持处理

用以下命令清除任何现有的 bbexample 文件

  $ bitbake -f -c cleansstate bbexample 

开始构建

  $ bitbake bbexample-rt 

Bitbake 将执行一系列任务，包括获取源存档、解包、配置、编译、安装和打包输出。

可能会出现一些警告，因为 bbexample、bbexample-rt 和 bbexample-lt 这三个配方生成相同的输出，因此共享文件存在一些冲突。这些警告可以忽略。

由于我们正在为模拟器 qemux86 构建，并且正在构建 RPM 包（默认），输出包将位于

~/yocto/poky-jethro-14.0.0/build_qemux86/tmp/deploy/rpm/i586/bbexample-rt-1.0-r0.0.i586.rpm

对于其他机器目标，文件夹和后缀 i586 将替换为不同的机器特定名称。要查找包的位置，您可以使用

  $ cd ~/yocto/poky-jethro-14.0.0/build_qemux86/tmp/deploy/rpm
  $ find -name bbexample-rt* 

（或者，用您正在构建的配方名称的前缀代替 bbexample-rt）

这将向您显示主软件包和 bitbake 为每个配方构建的辅助软件包，例如 -dev、-debug、-staticdev 等等。有关更多信息，请参见此处。

找到软件包后，您可以使用以下命令检查其内容是否符合预期：

  $ cd ~/yocto/poky-jethro-14.0.0/build_qemux86/tmp/deploy/rpm
  $ rpm -qlp i586/bbexample-rt-1.0-r0.0.i586.rpm 

对于 bbexample-rt 配方，我们期望看到交叉编译的可执行文件 bbexample 及其所需的共享库 libbbexample.so.1。

  /usr
  /usr/bin
  /usr/bin/bbexample
  /usr/lib
  /usr/lib/libbbexample.so.1
  /usr/lib/libbbexample.so.1.0.0

然后，您可以将此配方的输出添加到您的输出镜像中，方法是将类似以下内容添加到您的 conf/local.conf 中。

  IMAGE_INSTALL_append = " bbexample-rt" 

或者，您可以使用 Yocto 的 package-management 工具（例如 smart）使新软件包对现有目标系统可用。

如果您希望在模拟器上构建并测试您的示例，请跳至 [[#在目标上测试示例]]

基于本地源存档构建示例包

我们将要构建的配方是 /home/user/yocto/poky-jethro-14.0.0/meta-example/recipes-example/bbexample/bbexample-lt_1.0.bb。

这基于之前从远程源发布构建的配方，主要区别在于我们正在从本地源 tarball 构建。

这个 tarball 理论上可以包含我们希望构建的任何源代码，尽管有时构建失败可能需要修补源代码，并且如果未提供 autotools，则配方可能需要通过 do_install 函数进行扩展，以确保安装了适当的文件，并修改 FILES_${PN} 变量以确保安装的文件正确打包。

对于这个简单的例子，我们上传到 GitHub 的发布源存档已本地复制到 meta-example 层文件夹树中，路径为 yocto/poky-jethro-14.0.0/meta-example/recipes-example/bbexample/bbexample-lt-1.0/bbexample-v1.0.tar.gz。

这个本地文件就是我们在配方 SRC_URI 中设置的，用于复制、解包、打补丁（如果需要）和构建。

主要注意事项是

 

• SRC_URI 设置为指向本地文件存档

 

  SRC_URI = "file://bbexample-${PV}.tar.gz" 

 

• 理想情况下，我们将同时使用变量 ${PN} 和 ${PV}，它们将被替换为配方名称和配方版本，并且通常可以预期与源存档文件采用的命名约定相对应。这使得配方更通用，并且通过重命名配方 .bb 文件更容易更新到新版本的源代码。但是，由于我使用的是稍微不同的配方名称 bbexample-lt，我在此处硬编码了名称。

• 我们提供一个搜索路径以确保 bitbake 能够找到存档。

 

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

 

 

在这种情况下，上述内容将展开为以下文件夹，即我们放置 bbexample-1.0.tar.gz 的位置，因此 bitbake 将找到它进行解包 ~/yocto/poky-jethro-14.0.0/meta-example/recipes-example/bbexample/bbexample-lt-1.0。

 

• 这里没有 SRC_REV，也没有本地存档的校验和。
• 定义了一个 LICENSE 变量以向构建环境（MIT）指示许可证类型，以及另一个变量，
• LIC_FILES_CHKSUM 指向源树中的一个文件，该文件将被检索，并附带相应的 md5 校验和，以确保有人实际验证了源许可证文件与提供给构建环境的许可证文件相符。此外，还确保该文件（以及可能存在的许可证）没有随时间变化。

• 配方构建的源目录 ${S} 设置为 "bbexample-${PV}"，这对应于从本地存档中提取源代码后的路径。

 

  # Make sure our source directory (for the build) matches the directory structure in the tarball
  S = "${WORKDIR}/bbexample-${PV}" 

 

• 我们继承了一个名为 autotools 的类，它提供了功能，使 bitbake 能够自动构建支持 autotools 的项目。
• 这里明显缺少 do_install 函数，您可能在其他地方见过，因为这已由 autotools 支持处理

用以下命令清除任何现有的 bbexample 文件

  $ bitbake -f -c cleansstate bbexample bbexample-rt

开始构建

  $ bitbake bbexample-lt 

Bitbake 将执行一系列任务，包括从本地文件系统获取源存档、解包、配置、编译、安装和打包输出。

可能会出现一些警告，因为 bbexample、bbexample-rt 和

bbexample-lt 正在生成相同的输出，因此存在一些共享文件冲突。这些警告可以忽略。

由于我们正在为模拟器 qemux86 构建，并且正在构建 RPM 包（默认），输出包将位于 ~/yocto/poky-jethro-14.0.0/build_qemux86/tmp/deploy/rpm/i586/bbexample-lt-1.0-r0.0.i586.rpm。

对于其他机器目标，文件夹和后缀 i586 将替换为不同的机器特定名称。要查找包的位置，您可以使用

  $ cd ~/yocto/poky-jethro-14.0.0/build_qemux86/tmp/deploy/rpm
  $ find -name bbexample-lt* 

（或者，用您正在构建的配方名称的前缀代替 bbexample-lt）

这将向您显示主软件包和 bitbake 为每个配方构建的辅助软件包，例如 -dev、-debug、-staticdev 等等。有关更多信息，请参见此处。

找到软件包后，您可以使用以下命令检查其内容是否符合预期：

  $ cd ~/yocto/poky-jethro-14.0.0/build_qemux86/tmp/deploy/rpm
  $ rpm -qlp i586/bbexample-lt-1.0-r0.0.i586.rpm 

对于 bbexample-lt 配方，我们期望看到交叉编译的可执行文件 bbexample 及其所需的共享库 libbbexample.so.1。

  /usr
  /usr/bin
  /usr/bin/bbexample
  /usr/lib
  /usr/lib/libbbexample.so.1
  /usr/lib/libbbexample.so.1.0.0

然后，您可以将此配方的输出添加到您的输出镜像中，方法是将类似以下内容添加到您的 conf/local.conf 中。

  IMAGE_INSTALL_append = " bbexample-lt" 

或者，您可以使用 Yocto 的 package-management 工具（例如 smart）使新软件包对现有目标系统可用。

如果您希望在模拟器上构建并测试您的示例，请跳到“测试目标上的示例”。

在模拟目标上测试示例

为此，我们首先需要将相应的配方添加到映像中，然后在我们的模拟器目标中运行该映像。当然，我们也可以针对真实的板卡，但由于可用的板卡种类繁多，这超出了本指南的范围，您应该查阅您的板卡供应商提供的文档。

通过 local.conf 向映像添加软件包

至少有几种方法可以将新包添加到映像中。最简单的方法是将包添加到 local.conf 中的变量。

  $ cd ~/yocto/poky-jethro-14.0.0/build_qemux86/
  $ nano conf/local.conf 

在底部添加一行。您可能希望使用 bbexample-rt 或 bbexample-lt 而不是 bbexample。输出文件应该没有区别。

  IMAGE_INSTALL_append = " bbexample" 

然后 bitbake 构建您选择的镜像。使用此方法，您构建的任何镜像都将添加 bbexample 包。

用以下命令清除任何现有的 bbexample 文件

  $ bitbake -f -c cleansstate bbexample bbexample-rt bbexample-lt

然后构建

  $ bitbake core-image-minimal 

通过 .bbappend 将软件包添加到映像

或者，您可能希望将特定软件包添加到特定镜像中，这通常被认为是更好的做法。本指南我们使用 core-image-minimal。此镜像的配方可在 ~/yocto/poky-jethro-14.0.0/meta/recipes-core/images/core-image-minimal.bb 中找到。

我们还在使用我们自己的新 meta-example 层，所以这里似乎是添加 .bbappend 以扩展原始 core-image-minimal 配方的合适位置。

我们需要在自己的层中重新创建原始配方的路径，因此

  $ cd ~/yocto/poky-jethro-14.0.0/meta-example
  $ mkdir -p recipes-core/images
  $ cd recipes-core.images
  $ nano core-image-minimal.bbappend 

 

将以下行添加到您的空新文件中

  IMAGE_INSTALL += " bbexample" 

（确保您的 conf/local.conf 中不再包含 bbexample。这不会破坏构建，但您希望确保您的 .bbappend 正常工作。）

现在构建镜像

  $ cd ~/yocto/poky-jethro-14.0.0/build_qemux86
  $ bitbake core-image-minimal 

在模拟器中运行镜像

要启动镜像，只需使用

  $ runqemu qemux86 

这将启动模拟器，加载映像，您将看到内核加载，并且在 core-image-minimal 中看到一个控制台提示符。如果您构建的是 core-image-sato，则会看到一个基本的用户界面。

如果您发现键映射不正确，您可能希望明确设置它，例如

  $ runqemu qemux86 qemuparams='-k en-gb' 

或

  $ runqemu qemux86 qemuparams='-k en-us' 

以“root”身份登录模拟器，无需密码并运行示例

 $ bbexample  

您将看到 Hello World 输出！

配方陷阱

错误的源文件夹 ${S}

确保源文件夹，即 ${S} 变量设置正确，这一点极其重要。

从 git 仓库检索文件或解压存档时，源文件夹默认值很可能与实际解压后的源文件位置不符。

如果发生这种情况，构建将失败，通常会显示“找不到 LICENSE 文件”的错误消息，因为此文件在解包初期就已检查。

要检查这一点，一种选择是使用以下命令进入开发 shell：

  $ bitbake -c devshell recipename

这将把你带到 ${S} 的配置位置。如果 SRC_URI 中定义的源似乎已正确检索，但你在 devshell 中看不到任何东西，除了可能有一个 patches 文件夹，这表明代码已解压到不同的文件夹中。

  $ cd ..
  $ ls 

您通常会在 ${S} 目录级别上方看到另一个包含源代码的文件夹。

在这种情况下，您需要退出 devshell 并编辑您的配方以修改源目录以指向正确的位置。例如：

  ${S} = "${WORKDIR}/correctfoldername" 

然后回到开发外壳，应该会显示正确的文件，并且您应该能够继续构建。

许可证校验和不正确

这可能会发生，尤其是在将配方升级到使用新的仓库提交或源存档版本时，因为许可文件可能已更改。

如果确实发生这种情况，检查新的许可文件以确保构建环境仍然收到有关源代码许可证类型的正确信息非常重要。

也可能是文件进行了小的文本更改（例如新的版权日期），这不会影响许可证本身的类型。

确认配方中的 LICENSE 变量报告了正确的许可证类型后，您可以通过修改 LIC_FILES_CHKSUM 将许可证校验和更新为 bitbake 报告的值。

源存档校验和不正确

您应该注意，有时维护者会以相同的名称但内容更新的方式重新发布存档。如果发生这种情况，校验和检查将失败，您将需要调查这是否是因为下载损坏（检查 ~/yocto/poky-jethro-14.0.0/build_qemux86/downloads 中的下载存档）或者存档是否确实已更改。

 

• 您可以尝试从下载文件夹中删除存档，以及相应的 .done 文件。然后存档将再次下载，如果下载损坏/中断，这可能会奏效（尽管根据我的经验，这种情况不太可能发生）。

• 或者，存档可能已更改，您可能希望使用新存档，在这种情况下，您需要将配方中的校验和更新为通过 md5sum 和 sha256sum 在存档上自行计算的值，或者直接使用 bitbake 在日志中计算并提供给您的值。

 

  SRC_URI[md5sum] = "???"
  SRC_URI[sha256sum] = "???" 

 

• 最后，您也许可以从镜像或通过 Google 找到正确的存档文件，然后将其放入 downloads 文件夹供 bitbake 使用。

• 在后两种情况下，您可能希望将问题反馈给 Yocto 邮件列表（或配方所在层的其他相关邮件列表），因为此类问题意味着主源的镜像副本变得不同步，并且层/镜像维护者可能希望解决此问题。

 

缺少源存档

这不像过去那样是一个问题，因为主要来源现在被镜像在一个或多个位置，尤其是在某些情况下由 Yocto 项目本身进行镜像。

您也可以设置自己的镜像源，这在 [[How_do_I#Q:How do I create my own source download mirror? | 此处]] 有说明

然而，对于一次性缺失的存档，通常最快最简单的方法是 Google 查找，然后将其放入 ~/yocto/poky-jethro-14.0.0/build_qemux86/downloads 文件夹，并创建一个空的 .done 文件：

  $ touch archivename.done 

然后它应该会被 bitbake 拾取并使用。

反馈

这是一份动态文档。欢迎随时将评论、问题、更正发送给 Alex Lennon 此处。

原始文章托管在 此处。