在Yocto Dunfell发行版编译旧版3.14内核的技术求助

问题背景 #

我有一款搭载自定义3.14版本内核的嵌入式设备，此前一直使用Jethro发行版生成内核和文件系统镜像。现计划将开发环境升级至Dunfell发行版，但遇到了核心兼容性问题：Dunfell自带的新版GCC无法编译3.14内核。

尝试将Jethro中的gcc_4.9配方复制到Dunfell中，指定设备使用该版本GCC（及对应glibc），但过程中遇到两大障碍：

• glibc和gcc的配方结构发生大幅变化，环境变量差异极大：比如不再存在glibc-initial包，且所有glibc版本都不再提供virtual/${TARGET_SYS}libc-for-gcc虚拟包
• gcc配方的环境变量、依赖项等大量变更，推测官方为适配新结构修改了源码（比如提供空头文件，因此不再需要-initial包），这一过渡发生在Thud与Warrior发行版之间

求助需求 #

1. 若熟悉Thud到Warrior之间gcc/glibc配方/源码过渡的细节，能否解释该变化的核心逻辑或相关实现细节
2. 是否有人拥有适用于Dunfell的版本≤7.0的可用gcc/libc包
3. 希望得到可落地的解决方案思路

解决方案思路 #

1. 独立维护旧版交叉工具链 #

不在Dunfell主构建系统内强行适配旧gcc，而是单独用Jethro构建出gcc 4.9的交叉工具链，然后在Dunfell的设备配置文件中通过EXTERNAL_TOOLCHAIN变量指定该工具链路径，同时调整内核编译配置，确保使用旧工具链的头文件与库资源。这种方式避开了Dunfell对工具链的重构逻辑，直接复用成熟的旧版本工具链。

2. 为旧内核打新GCC兼容补丁 #

尝试给3.14内核打补丁，适配Dunfell自带的新版GCC（如GCC 9.x）。重点处理编译器报错的场景：比如新警告被触发为错误、语法兼容性问题、内置函数调用差异等。社区中存在不少旧内核适配新GCC的补丁集合，可以针对性查找并移植。

3. 集成第三方兼容meta层 #

查找第三方维护的meta层，这类层通常会在较新的Yocto发行版中保留对旧版本gcc/glibc的支持。将这类meta层集成到Dunfell构建系统中，直接复用现成的适配配方，避免手动修改的繁琐。

Thud到Warrior的gcc/glibc配方过渡说明 #

在Thud到Warrior的迭代中，Yocto项目对工具链构建流程做了核心重构，目的是简化逻辑、减少冗余：

• 移除glibc-initial等初始构建包：新版gcc与glibc源码中加入了空环境适配逻辑，比如提供默认头文件占位，不再需要单独的初始化阶段生成基础头文件
• 取消virtual/${TARGET_SYS}libc-for-gcc虚拟包：改为直接通过配方依赖关系管理gcc与glibc的版本匹配，gcc配方直接关联特定版本的glibc开发包，不再通过虚拟包间接跳转
• 重构gcc配方的环境变量：移除GCC_INITIAL这类旧变量，改用模块化的构建参数拆分工具链构建阶段，整体流程更自动化

低版本gcc/libc包获取建议 #

• 从Yocto旧版本（如Sumo、Thud）的meta层中提取gcc ≤7.0和对应glibc的配方，手动修改依赖项、环境变量以适配Dunfell的构建框架
• 部分嵌入式芯片厂商的开源meta层会为兼容旧内核，在Dunfell中保留低版本gcc支持，可以针对性查找对应厂商的资源

内容的提问来源于stack exchange，提问作者Attila Horvath