这事儿的核心原因在于静态库的链接逻辑是「按需引入」——链接器只会从静态库里提取那些当前还缺少符号定义的目标文件，不会一股脑把整个库都塞进去。咱们结合你的操作步骤拆解来看：

直接链接目标文件报错的原因 #

当你直接执行gcc -o main main.o foo.o foo2.o时，链接器会把这三个目标文件全部纳入链接流程。foo.o和foo2.o里都定义了fooxyz函数，链接器发现同一个符号被多次定义，自然就抛出多重定义错误了。

链接静态库时不报错的逻辑 #

再看你实际操作的流程：

1. 你先编译出了main.o、foo.o、foo2.o，然后把foo2.o归档成静态库libfoo2.a。
2. 执行链接命令gcc -o main main.o foo.o -L. -lfoo2时，链接器是按顺序处理输入文件的：
   • 首先处理main.o：它里面声明了fooxyz，但没有定义，所以链接器会记下这个未解决的符号。
   • 接着处理foo.o：这个目标文件正好定义了fooxyz，链接器立刻把这个符号标记为已解决。
   • 最后处理静态库libfoo2.a：链接器会遍历库中的每个目标文件（这里就是foo2.o），检查它能提供哪些符号。此时所有需要的符号都已经被解决了，foo2.o里的fooxyz完全是多余的，所以链接器根本不会把foo2.o从静态库里提取出来加入到最终的可执行文件中。

没有被纳入链接的目标文件，自然不会触发多重定义的冲突啦！

验证方法 #

你可以用nm main命令查看最终生成的可执行文件里的符号：

nm main | grep fooxyz

输出只会显示来自foo.o的fooxyz定义，完全找不到foo2.o相关的痕迹，这就证明foo2.o确实没被加入到可执行文件中。

额外补充 #

如果反过来操作——把foo.o做成静态库，链接main.o、foo2.o加上这个库——结果也是一样的，链接器只会用第一个能解决未定义符号的目标文件，静态库里的那个同名符号会被直接忽略。

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