buildroot构建swupdate报错libuboot.h缺失

说明

本篇文档记录了基于 buildroot 更换 swupdate 软件包的流程，包含有移植方法及移植过程中出现的问题处理。有类似 buildroot 下移植软件包的问题，可参考本文章。

背景

因功能需求，需要更换 buildroot 默认下载的 swupdate 软件包：当前使用的 buildroot 版本为2019.02，buildroot 默认下载的 swupdate 软件包版本为2018.11。

软件包更新替换流程

推荐替换方法：下载新版本的buildroot；用新版本 buildroot-xxx/package/swupdate 目录下的文件替换旧版本同目录下的文件（全部替换后，新版本不需要的或旧版本需要保留的文件，可通过更改swupdate.mk文件来适配）

软件包版本可在 buildroot-xxx/package/swupdate/swupdate.mk 中查看：​​​​​​​

buildroot下载地址：Index of /downloads (buildroot.org)

博主下载的是 2023.02 版本的 buildroot，这一版 buildroot 默认下载 2022.12 版本的 swupdate 软件包。

这里多提一嘴，因为 buildroot 默认下载的软件包版本，都是低于 buildroot 日期的；所以如果有可能，尽量直接更换新版本的 buildroot，而不是 buildroot 下的软件包；这样就可以让 buildroot 自行去处理软件包之间可能存在的依赖关系，而不需要自己手动去解决，一般移植软件包遇到的大多数问题，就是软件包之间的依赖。博主这次移植过程中，就是因为在旧版本 buildroot 的基础上使用新版本的 swupdate 包，才有了这篇文章的出现~

这里分两步来进行：

1. 首先直接编译swupdate，确保能编译通过。

2. 编译通过后，再加入自己的需求功能。

替换后直接编译swupdate

替换完swupdate相关配置文件后，首先直接编译swupdate，报错如图所示内容：

这是新旧版本 swupdate 差异，在 \buildroot-201902\package\swupdate\swupdate.mk 中搜索 “CONFIG_SYSTEMD” 相关内容并进行屏蔽（其他类似报错在不影响功能的前提下，都可以这样处理）：

屏蔽之后再次编译，编译通过，然后下一步就是加入自己的需求功能。

 

加入需求功能

注：下面的截图显示的目录信息会有两个日期，因为使用的 buildroot 软件包版本不变，所以是以新版本的 swupdate 代码为基准来适配的。

通过 swupdate 来实现 OTA 的 AB 升级方案，需要能读取 uboot 的环境变量，即在用户空间使用fw_printenv 和 fw_setenv 来读写 env 分区的变量，来设置下次启动的分区（比如当前运行在 bootA/rootfsA 分区，通过 AB 升级方案升级了 bootB/rootfsB 分区，则需要设置下次启动从 bootB/rootfsB 分区启动），该功能由 swupdate-2022.12\bootloader\uboot.c 文件支持。

查看swupdate源码，CONFIG_UBOOT 宏决定 uboot.c 文件是否参与编译：

在 buildroot-201902\package\swupdate\swupdate.config 中加入 CONFIG_UBOOT=y 配置项：

加入后开始编译，如图报错编译 uboot.c 时找不到 libuboot.h：

查看 uboot.c 源文件，如图所示：

这个问题是 swupdate 新旧软件包版本关于 uboot 的差异点之一：旧版本的 swupdate 读取 uboot 环境变量是由 uboot-tools 软件包支持的，而新版本的 swupdate 读取 uboot 环境变量是由 libubootenv 软件包支持，libuboot.h 文件也是由 libubootenv 软件包提供。所以对应新版本 swupdate，应该打开宏 BR2_PACKAGE_LIBUBOOTENV：

在 buildroot 的配置文件 \buildroot-201902\configs\xxx_defconfig 中进行宏配置：

重新编译，还是报错，而且 buildroot 编译生成的 .config 文件中不包含该宏，甚至连宏未打开时的 "BR2_XXX is not set" 都没有，怀疑可能是当前 buildroot 软件还未支持该宏，make munuconfig 搜索宏 BR2_PACKAGE_LIBUBOOTENV，如图显示没有找到：

在新版本的buildroot下 "make menuconfig" 搜索宏 BR2_PACKAGE_LIBUBOOTENV，显示在 buildroot-2023.02.3\package\libubootenv\Config.in 中：

这说明 libubootenv 是新版本的 buildroot 才加入的软件包，需要在旧版本的 buildroot 中进行适配：

1. 首先在 \buildroot-201902\package 目录下加入 libubootenv 的内容，可直接从新版本的 buildroot 中拷贝过来：

2. 在 \buildroot-201902\package\Config.in 文件中将 libubootenv 的 Config.in 包含进来，方便通过 make menuconfig 来配置：

3. 再次 make munuconfig 搜索宏 BR2_PACKAGE_LIBUBOOTENV，这次搜索到了，说明 buildroot 可以解析到 libubootenv 软件包的配置文件。

4. 现在 BR2_PACKAGE_LIBUBOOTENV 宏打开了，且在 \buildroot-201902\package 目录下也有 libubootenv 相关的配置文件，再次开始编译。

5. 检查 buildroot 编译生成的 .config 文件中，包含了 BR2_PACKAGE_LIBUBOOTENV 宏

且在 buildroot\build 编译输出目录下生成了 libubootenv-0.3.3 的软件包，说明 libubootenv 软件包成功下载下来了

而 libuboot.h 就静静的躺在 libubootenv 的软件包中：

6. 最后不出意外，编译也顺利通过了。

buildroot 对于软件包的管理，是有它自定义的一套规则。只需要按照 buildroot 规定的框架去添加，基本不会出太大的问题，然后出问题解问题就行。

buildroot软件包替换后编译，最常见的就是软件包的依赖问题，找不到依赖的包等。所以再次建议，如果有可能，尽量直接替换buildroot，而不是buildroot下的软件包。

buildroot 编译常见问题

问题1：Meson 版本过低

meson.build:1:0: ERROR:  Meson version is 0.49.0 but project requires >=0.53.0.

问题原因：构建 zchunk 软件包需求的 Meson 版本高于当前使用的 Meson 版本。

解决办法：使用新版本 buildroot 下 meson 软件包的配置替换 buildroot-201902\package\meson 下的所有文件（保留 cross-compilation.conf.in，编译时会用到）。

注：Meson 是用 Python 语言开发的构建工具，不同版本的 Meson 对应需要不同版本的 Python。替换 Meson 版本后，如果版本相差比加大，那很大概率也会需要使用新版本的 pyhton。

问题2：Meson 依赖的 python 版本过低

ERROR: Tried to install Meson with an unsupported Python version: （Meson requires Python 3.7.0 or greater）

问题原因：编译过程中，buildroot 会使用 Meson 来下载一些依赖包，而新版本 Meson 要求 Python 版本为 3.7.0 以上。

解决办法：开启宏 BR2_PACKAGE_PYTHON3

后续有遇到其他编译问题会继续补充 ...