别再折腾编译器了！U-Boot编译报错‘multiple definition of `yylloc‘‘的三种根治方案（附Fedora/Ubuntu实测）

根治U-Boot编译报错'multiple definition of `yylloc'‘的终极指南

在嵌入式Linux开发中，U-Boot作为系统启动的关键组件，其编译过程往往成为开发者面临的第一个技术挑战。最近，不少工程师反馈在交叉编译U-Boot时遭遇了顽固的multiple definition ofyylloc'`错误，特别是在Fedora等特定发行版环境下。这个看似简单的链接错误背后，实际上隐藏着编译器行为变更、源码兼容性以及构建系统配置等多重因素。本文将深入剖析问题本质，提供三种经过实测的解决方案，并分享在不同系统环境下的避坑经验。

1. 问题根源深度解析

当你在编译U-Boot时遇到multiple definition ofyylloc'`错误，终端通常会显示类似如下的报错信息：

/usr/bin/ld: scripts/dtc/dtc-parser.tab.o:(.bss+0x10): multiple definition of `yylloc'; scripts/dtc/dtc-lexer.lex.o:(.bss+0x0): first defined here collect2: error: ld returned 1 exit status

这个错误的本质在于yylloc变量在dtc-parser.tab.o和dtc-lexer.lex.o两个目标文件中被重复定义。这种现象源于GCC编译器的一个历史性行为变更：

• GCC 10的默认行为变化：从GCC 10开始，编译器默认使用-fno-common选项，这与之前版本默认的-fcommon行为相反
• -fcommon与-fno-common的区别：
  • -fcommon：允许多个目标文件定义同名全局变量，链接时合并为一个定义
  • -fno-common：严格检查全局变量的多重定义，发现重复立即报错

关键发现：U-Boot 1.7.4等较旧版本在设计时依赖了-fcommon的宽松行为，当现代编译器采用严格模式时，就会暴露出源码中的变量定义问题。

2. 解决方案一：修改源码注释法

最直接的解决方法是定位并修复源码中的重复定义问题。以下是详细操作步骤：

1. 定位问题文件：

   find . -name "dtc-lexer.lex.*" find . -name "dtc-parser.tab.*"

2. 修改lexer文件： 打开scripts/dtc/dtc-lexer.l，找到类似以下内容：

   YYLTYPE yylloc;

   将其修改为：

   extern YYLTYPE yylloc;

3. 清理并重新编译：

   make distclean make your_defconfig make

优缺点分析：

提示：这种方法在U-Boot主线版本中已被采纳，但在一些厂商定制版中可能仍需手动修复。

3. 解决方案二：修改编译选项法

更系统化的解决方案是通过修改构建系统的编译选项，恢复传统的-fcommon行为。具体实施有两种方式：

3.1 修改顶层Makefile

1. 打开U-Boot根目录下的Makefile文件
2. 找到HOSTCFLAGS或KBUILD_CFLAGS的定义处
3. 添加-fcommon选项：

   HOSTCFLAGS += -fcommon KBUILD_CFLAGS += -fcommon

3.2 通过环境变量传递

或者，你也可以在编译时通过环境变量传递选项：

make HOSTCFLAGS="-fcommon" CFLAGS="-fcommon" your_defconfig make

实测效果对比：

我们在Fedora 35和Ubuntu 20.04上测试了这种方法：

适用场景：

• 当你无法或不想修改源码时
• 需要快速验证解决方案时
• 在多项目环境中保持一致性时

4. 解决方案三：更换宿主系统法

如果你不想修改任何代码或构建配置，更换宿主系统可能是最简单的解决方案。我们的测试发现：

• Fedora/RHEL系：从Fedora 33开始默认使用GCC 10+，容易出现此问题
• Ubuntu LTS：20.04默认使用GCC 9，通常不会遇到此问题
• Debian stable：同样使用较旧的GCC版本，兼容性较好

系统切换建议：

1. 临时解决方案：

   docker run -it --rm -v $(pwd):/work ubuntu:20.04 apt update && apt install build-essential git

2. 长期方案：

   • 为嵌入式开发专门配置Ubuntu LTS环境
   • 使用虚拟机或容器隔离开发环境

性能对比数据：

5. 进阶技巧与深度优化

对于需要长期维护U-Boot的开发者，以下进阶建议可能有所帮助：

5.1 自动化检测脚本

创建一个预处理脚本，自动检测并修复常见问题：

#!/bin/bash # 检查GCC版本 gcc_version=$(gcc -dumpversion) if [[ $(echo "$gcc_version >= 10" | bc) -eq 1 ]]; then echo "检测到GCC 10+，可能需要特殊处理" export CFLAGS="-fcommon" fi # 检查U-Boot版本 if grep -q "UBOOT_VERSION = 1.7.4" Makefile; then echo "检测到旧版U-Boot，应用补丁..." [ -f scripts/dtc/dtc-lexer.l ] && sed -i 's/^YYLTYPE yylloc;/extern YYLTYPE yylloc;/' scripts/dtc/dtc-lexer.l fi

5.2 构建环境容器化

使用Docker创建可重复的构建环境：

FROM ubuntu:20.04 RUN apt-get update && \ apt-get install -y build-essential git bc bison flex libssl-dev WORKDIR /build COPY . . ENV CFLAGS="-fcommon" RUN make your_defconfig && make -j$(nproc)

5.3 交叉编译器选择建议

不同交叉编译器对-fcommon的支持也有所不同：

在实际项目中，我们遇到过这样一个案例：某团队使用Fedora 35编译RK3399的U-Boot时遇到此问题。他们首先尝试了修改源码，但由于厂商SDK的自动更新机制导致修改频繁丢失。最终解决方案是在CI流程中增加了export CFLAGS="-fcommon"，既解决了问题又保持了代码的原始性。