静态C库是否会引发文件名冲突？为何链接同名.o文件无报错？

问题描述 #

我制作的静态C库libmylib.a包含array.o、linkedlist.o这类常见文件名的目标文件。如果使用该库的用户自己也有同名的array.c和linkedlist.c文件，编译时会不会报错？共享库也存在这个问题吗？

我用下面的Makefile测试后没出现报错，想知道为什么存在两个array.o文件时链接不会报错：

OBJECTS = array.o main.o

main: $(OBJECTS)
    gcc $(OBJECTS) -Llibs/ -lmylib -lm

array.o: array.c array.h
    gcc -c array.c

main.o: main.c
    gcc -c main.c

问题解答 #

1. 静态库为何没报错

链接器处理目标文件和静态库的顺序是核心原因：

• 你的Makefile里，先把用户自己编译生成的array.o、main.o传给链接器，之后才指定链接libmylib.a。
• 链接器处理目标文件时，会把里面所有的符号（函数、变量等）都纳入最终可执行文件。后续处理静态库时，链接器只会从库中提取当前还未定义的符号对应的目标文件。
• 由于用户自己的array.o已经提供了array.c里的所有符号，链接器完全不需要再从静态库中提取array.o，自然不会出现符号冲突，也就不会报错。

要是把链接顺序反过来，写成gcc -Llibs/ -lmylib -lm $(OBJECTS)，链接器会先提取静态库的array.o，之后处理用户的array.o时就会触发重复定义的符号错误。

2. 共享库的情况

共享库的处理逻辑和静态库有本质区别：

• 共享库在编译链接阶段不会把代码直接合并到可执行文件，而是等程序运行时才动态加载。
• 如果用户自己的array.o和共享库中的array.o有同名符号，分两种场景：
  • 对于全局符号（C语言默认的符号都是全局的），链接阶段不会报错，但程序运行时会优先使用进程中先加载的符号（一般是用户自己编译的代码里的符号，因为可执行文件的符号会先于共享库加载），这会导致共享库中的同名符号被覆盖，很可能引发意料之外的逻辑错误。
  • 如果编译共享库时用-fvisibility=hidden参数，把库内非必要符号设为隐藏，只导出需要对外暴露的符号，就能有效避免这种冲突。

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