Clang是否依赖链接的共享库决定符号导出？实测差异分析

测试代码 #

main.c #

void foo() {}
int main() { return 0; }

bar.c（初始版本） #

void foo();
void bar() { foo(); }

GCC编译测试 #

使用无优化编译命令：

$ gcc -fpic -shared -o libbar_gcc.so bar.c
$ gcc -L. -lbar_gcc -o prog_gcc main.c

查看动态符号表，确认foo未从可执行文件导出：

$ readelf --dyn-syms prog_gcc | grep foo
$

Clang编译测试 #

场景1：链接调用foo的共享库 #

编译命令：

$ clang -fpic -shared -o libbar_clang.so bar.c
$ clang -L. -lbar_clang -o prog_clang main.c

动态符号表显示foo被导出：

$ readelf --dyn-syms prog_clang | grep foo
    6: 0000000000001130     6 FUNC    GLOBAL DEFAULT   13 foo

场景2：不链接共享库 #

编译命令：

$ clang -fpic -shared -o libbar_clang.so bar.c
$ clang -o prog_clang main.c

foo未被导出：

$ readelf --dyn-syms prog_clang | grep foo
$

场景3：链接不调用foo的共享库 #

修改后的bar.c：

void bar() { }

编译命令：

$ clang -fpic -shared -o libbar_clang.so bar.c
$ clang -L. -lbar_clang -o prog_clang main.c

foo再次未被导出：

$ readelf --dyn-syms prog_clang | grep foo
$

问题核心 #

修改依赖共享库的代码（未改动可执行文件源码或链接方式），为何会改变Clang对可执行文件符号导出的决策？

原因分析 #

这是Clang与GCC在符号解析、导出联动逻辑上的差异导致的，核心在于链接阶段的符号依赖追踪：

1. 共享库的未定义符号标记：当bar.c调用foo时，编译生成的libbar_clang.so会在动态符号表中标记foo为未定义符号（UND）。
2. 链接器的动态符号导出逻辑：Clang默认会让链接器追踪共享库的未定义符号需求。链接prog_clang时，链接器发现libbar_clang.so需要foo，而该符号定义在main.c中，因此会将foo标记为动态可见，导出到.dynsym段，确保运行时共享库能找到该符号。
3. 无依赖时的符号隐藏优化：当共享库不引用foo时，链接器判定该符号无需被外部共享库访问，因此不会将其导出到动态符号表，这和GCC的默认行为一致。

简言之，Clang会根据链接的共享库是否存在对某个符号的未定义引用，动态决定是否将该符号从可执行文件中导出——仅当共享库需要时，符号才会被动态导出。

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