4. 理解Yocto版本间的差异：核心层（OE-Core）的变化、BitBake语法与功能更新、关键软件包版本的变更
说实话，很多团队升级Yocto时翻车，不是因为不会配layer，而是没搞懂版本之间到底变了什么。你想想看，一个构建系统牵涉到几百个recipe、一套元语言解释器、还有底层工具链的版本——任何一个环节脱节，构建就炸了。
这一章，我就带你拆开这三个维度：OE-Core、BitBake、关键软件包。搞懂了它们，你才算真正看懂了Yocto的版本号。
核心观点：Yocto版本升级，本质上是对OE-Core快照的切换。BitBake是引擎，OE-Core是货架，软件包版本是货架上的商品。引擎升级了，货架结构变了，商品换新了——三者必须对齐。
4.1 OE-Core：你的构建地基变了没？
OE-Core是Yocto项目的核心元数据集合。说白了，所有recipe、class、conf文件，大部分都躺在这里。每次大版本升级，OE-Core都会有一次“快照切换”。
我遇到过最典型的坑：有人从Yocto 3.1 (Dunfell) 直接跳到 4.0 (Kirkstone)，结果构建到一半报错说 inherit 找不到某个class。查了半天，原来是OE-Core里把 meta/classes 拆成了 meta/classes-global 和 meta/classes-recipe。你想想看，你的layer里如果硬编码了路径，那肯定炸。
4.1.1 层结构的变化
从Yocto 4.0开始，OE-Core对class文件做了重新组织：
| Yocto 版本 | OE-Core 快照 | class 目录结构 | 关键变化 |
|---|---|---|---|
| 3.1 (Dunfell) | dunfell-23.0.0 | meta/classes/ |
所有class平铺 |
| 4.0 (Kirkstone) | kirkstone-4.0.0 | meta/classes-global/ + meta/classes-recipe/ |
按作用域拆分 |
| 5.0 (Scarthgap) | scarthgap-5.0.0 | 同上，新增 classes-recipe 子目录细化 |
部分class改名 |
我的建议：升级前先跑 bitbake-selftest 检查你的layer是否引用了已废弃的class路径。我曾经在Dunfell升Kirkstone时，光修路径就花了半天。
4.1.2 Recipe 语法的演进
OE-Core里的recipe写法也在变。举个例子，SRC_URI 的 md5sum 校验在Kirkstone之后被标记为废弃，推荐改用 sha256sum。还有 PACKAGECONFIG 的写法，从 pkgconfig 改成了 pkg-config。
# Dunfell 时代的写法（还能用，但会报警告）
SRC_URI[md5sum] = "abc123..."
SRC_URI[sha256sum] = "def456..."
# Kirkstone 之后的推荐写法
SRC_URI[sha256sum] = "def456..."
# md5sum 字段不再建议使用注意：如果你在Kirkstone上继续用 md5sum，BitBake会打印deprecation warning。虽然构建不会失败，但CI日志里会多出一堆噪音。我建议直接清理掉。
4.2 BitBake：引擎升级，语法跟着变
BitBake是Yocto的构建引擎。每次OE-Core快照切换，都会绑定一个最低BitBake版本。比如Dunfell要求BitBake >= 1.46，Kirkstone要求 >= 2.0。
我个人习惯在升级前先看一眼 meta/conf/bitbake.conf 里的 BB_VERSION 注释，确认当前OE-Core期望的BitBake版本。
4.2.1 语法更新清单
从BitBake 1.x 到 2.x，有几个变化你一定要注意：
- 变量展开顺序：BitBake 2.0 开始，
_append/_prepend/_remove的优先级被重新定义。以前_append在_remove之后执行，现在反过来。这会导致你的override行为发生变化。 - Python函数签名：
def python_func(d):这种写法在2.0之后被严格检查。如果你漏了d参数，会直接报错。 - 任务依赖：
addtask的after和before关键字现在支持更复杂的表达式，但旧写法仍然兼容。
# BitBake 1.x 风格（Dunfell）
python do_printdate() {
import datetime
print(datetime.datetime.now())
}
addtask do_printdate after do_configure before do_compile
# BitBake 2.x 风格（Kirkstone+）
python do_printdate() {
import datetime
bb.note(str(datetime.datetime.now())) # 推荐用 bb.note 替代 print
}
addtask do_printdate after do_configure before do_compile避坑指南：我曾经在升级后遇到一个诡异问题——_remove 操作没有生效。查了两天才发现是BitBake 2.0改了override的解析顺序。解决方案很简单：把 _remove 挪到 _append 之后，或者用 _overrides 显式指定顺序。
4.2.2 新功能：BB_HASH_COLLISION
BitBake 2.2 引入了一个新变量 BB_HASH_COLLISION，用于检测hash冲突。这在多用户协作时特别有用。我建议在升级后把这个变量设为 warn 或 error，避免因为hash碰撞导致构建结果不一致。
# 在 local.conf 中启用
BB_HASH_COLLISION = "warn"4.3 关键软件包版本的变更
Yocto版本升级，最直观的变化就是工具链和核心库的版本。GCC、glibc、Linux内核、QEMU——这些家伙的版本号一跳，你的应用层可能就要跟着改。
4.3.1 版本对照表
| Yocto 版本 | GCC | glibc | Linux 内核 (默认) | QEMU |
|---|---|---|---|---|
| 3.1 (Dunfell) | 9.3 | 2.31 | 5.4 | 5.0 |
| 4.0 (Kirkstone) | 11.3 | 2.35 | 5.15 | 6.2 |
| 5.0 (Scarthgap) | 13.2 | 2.39 | 6.6 | 8.1 |
你看，从Dunfell到Kirkstone，GCC从9.3跳到11.3。这意味着什么？你的代码如果用了C++17甚至C++20的特性，在Dunfell上可能编译不过，但在Kirkstone上就OK。反过来，如果你的代码依赖了GCC 9.x的某些行为（比如 -fno-strict-aliasing 的默认值），升级后可能跑出不同的结果。
我的经验：每次升级前，我会先建一个空的测试镜像，只包含 core-image-minimal，然后跑一遍 testimage。这样能快速发现工具链版本变化导致的底层问题，而不是等到集成测试才暴露。
4.3.2 glibc 版本跳坑
glibc 2.35 引入了一些新API，比如 gettid 不再是系统调用封装，而是直接暴露为函数。如果你的代码里用了 syscall(SYS_gettid)，在Kirkstone上仍然能跑，但会收到一个deprecation警告。我建议趁升级的机会，把这些旧调用换成新API。
// 旧写法（Dunfell）
#include <sys/syscall.h>
pid_t tid = syscall(SYS_gettid);
// 新写法（Kirkstone+）
#include <unistd.h>
pid_t tid = gettid();4.4 如何快速评估版本差异？
说了这么多，你可能想问：有没有一个快速的方法，能让我一眼看出两个Yocto版本之间的差异？
有。我常用的方法是：
- 下载两个版本的OE-Core源码，用
diff -rq对比meta/recipes-*目录。 - 查看
meta/conf/distro/include/tcmode-default.inc，这里定义了默认工具链版本。 - 运行
bitbake -s | grep -E "gcc|glibc|linux-yocto"查看实际使用的版本。
一句话总结：Yocto版本升级，不是简单的“换个分支拉代码”。OE-Core的结构、BitBake的语法、软件包的版本——这三者必须一起评估。跳过任何一环，你都会在构建的中后期付出代价。