为什么gcc参数顺序会影响编译出的共享库的readelf -d输出结果

这一现象是由GCC调用的链接器ld的默认工作规则直接导致的：

• ld处理命令行输入参数的顺序是严格从左到右，对动态链接库的加载判断遵循「按需依赖」规则：只有当处理到-l指定的库时，当前已经存在待解析的未定义符号确实需要该库提供实现，ld才会将该库标记为共享库的NEEDED依赖项；如果处理-l库时还没有出现需要它解决的未定义符号，该库会被直接忽略，后续产生的未定义符号也不会回头再查找前面跳过的库。

结合你给出的两个编译命令具体分析：

1. 第一条命令 gcc -shared -o libbar2.so -fPIC bar.c -lfoo -L.
   处理顺序是先编译bar.c生成目标代码，此时bar()调用的foo()会被标记为未定义符号，之后再处理-lfoo时，ld发现libfoo.so可以解决未定义的foo()符号，因此会将libfoo.so添加到动态依赖的NEEDED列表中，所以libbar2.so的readelf -d输出会包含libfoo.so。

2. 第二条命令 gcc -shared -o libbar.so -lfoo -L. -fPIC bar.c
   处理顺序是先遇到-lfoo，此时还没有处理bar.c，不存在需要libfoo.so解决的未定义符号，ld直接跳过了-lfoo的关联逻辑；后续处理bar.c产生未定义的foo()符号时，不会再回溯查找前面跳过的libfoo.so，因此最终生成的libbar.so不会把libfoo.so加入NEEDED依赖。

至于两个库大小一致但校验值不同的问题：两个库的可执行代码段、基础数据段的总大小刚好相同，所以文件总大小一致；但二者的.dynamic节（存储动态依赖等元信息）内容不同，还有其他编译生成的元数据存在差异，因此校验值不同。

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