Linux下gcc链接multiple definition错误的问题分析与解决

问题1：重命名Hello()符号是解决该问题的唯一正确方案吗？ #

不是，目前常见的合规解决方案有两类：

• 符号作用域限制：如果某函数仅在当前编译单元（单个.c/.s文件）内部调用，不需要对外暴露，直接将其设置为内部链接即可，C语言中对应static关键字，UASM汇编中对应PROC PRIVATE FRAME声明，该方案是最贴合你业务场景的最优解，不需要修改函数名也不会产生符号冲突。
• 符号重命名：如果两个Hello()都需要对外暴露为全局符号，才需要通过重命名、增加前缀等方式区分符号，该方案仅适用于函数必须全局可见的场景。

问题2：使用--allow-multiple-definition选项是否属于不良开发实践？ #

是，正常开发场景下属于强烈不推荐的用法，原因如下：

• 该选项直接绕过了C语言的单定义规则，符号最终绑定的实现完全由链接顺序决定，一旦后续调整编译链接顺序，程序运行逻辑会发生不可预期的变化，排查成本极高。
• 该选项仅适用于临时调试、兼容老旧无源码二进制文件等极端特殊场景，禁止在生产代码的编译脚本中使用。

问题3：链接器是否可以通过限制函数可见性来匹配预期逻辑？ #

可以，你尝试的static关键字就是这个逻辑的实现：
默认情况下没有加特殊声明的C函数都是全局外部符号，链接器处理全局符号的规则是「找到第一个匹配定义后，将所有对该符号的引用都绑定到这个定义上」。而给函数加上static关键字后，该符号会被标记为内部链接，仅对当前编译单元可见，不会参与全局符号的解析：

1. A.c里的全局Hello()和B.c里的内部Hello()完全独立，不会产生冲突
2. B.c内World()对Hello()的调用会优先绑定本编译单元的内部符号，不会调用A.c的全局实现
   除了static外，GCC扩展的__attribute__((visibility("hidden")))也可以实现类似效果，主要用于动态库场景下隐藏不需要对外暴露的全局符号。

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