【链接器探秘】L6200E：从“重复定义”到“唯一地址”的链接器裁决

原创

于 2026-03-10 00:52:33 发布 · 225 阅读

标签

1. 当链接器敲响警钟：初识L6200E错误

刚接触嵌入式开发，特别是用ARM的Keil MDK或者IAR这类工具链的朋友，十有八九都见过这个让人头疼的错误：L6200E: Symbol multiply defined。我第一次遇到它的时候，正在调试一个STM32的小项目，屏幕上突然跳出这么一行红字，项目死活链接不过去，当时真是一头雾水。这个错误就像一个严厉的裁判，在你即将把各个模块“组装”成最终程序时，吹响了哨子，告诉你：“停！这里有问题，同一个名字出现了两次，我没办法决定用哪个。”

简单来说，L6200E错误就是链接器（Linker）在向你报告它发现了“重复定义”的符号。这里的“符号”（Symbol），可以理解为一个标签或者名字，它可能代表一个全局变量、一个函数。而“定义”，就意味着实实在在地为这个符号分配了内存空间。想象一下，你在管理一个巨大的仓库（内存），每个货物（变量或函数）都需要一个唯一的货架编号（内存地址）。现在，你手上有两份来自不同部门的入库单（main.o和sensor.o），它们都给同一种货物（比如system_uptime_ms）指定了不同的货架位置。作为仓库管理员（链接器），你该听谁的？你没法决定，只能上报错误。

这个错误的典型场景，就像原始文章里模拟的那样，往往源于一个看似无害的坏习惯：在头文件（.h）里直接定义并初始化全局变量。比如，你在shared.h里写了一句uint32_t system_uptime_ms = 0;，然后这个头文件被main.c和sensor.c都包含了。编译器（Compiler）是个老实人，它分别处理每个.c文件。当它编译main.c时，看到这行代码，就会在main.o这个目标文件里，为system_uptime_ms预留4个字节的空间，并记下它的名字和初始值。接着，它去编译sensor.c，又看到了完全一样的一行代码，于是它在sensor.o里，又为另一个同名的system_uptime_ms预留了4个字节的空间。这两个目标文件本身都没问题，都能独立生成。

麻烦出在链接阶段。链接器的工作是把所有零散的.o文件“缝合”成一个完整的可执行文件（比如.axf或.elf）。当它试图合并main.o和sensor.o时，在整理全局符号表的时候傻眼了：它发现了两个都声称自己“拥有”system_uptime_ms这个符号的目标文件。它无法判断该把程序中所有对system_uptime_ms的访问请求，导向main.o里的那个地址，还是sensor.o里的那个地址。这种不确定性是致命的，会导致程序运行混乱，因此链接器必须果断报错，停止工作。所以，L6200E不是一个编译错误，而是一个链接错误，它揭示了多模块协作中关于“所有权”的根本矛盾。