GCC编译动态库时文件顺序及依赖库类型导致运行时符号未定义问题咨询

嗨，我来帮你拆解一下这个问题背后的核心原因，其实都是GCC链接器的工作逻辑在起作用，咱们一步步来看：

一、静态库与目标文件的顺序为何会影响动态库的符号解析？ #

GCC的链接器处理输入文件的规则是从左到右依次扫描，对于静态库（.a文件），它只会做一件事：检查当前是否有未被解析的符号，如果有，就从静态库里提取对应的目标文件来填补这些符号；如果没有，就直接跳过这个静态库，不会把库里的内容打包到输出文件里。

• 当你用gcc -o libfunc2.so -shared -fPIC libfunc1.a func2.o编译时：
  链接器先处理libfunc1.a，这时候还没扫描到func2.o，不存在未定义的show符号，所以直接跳过静态库，没有把func1.o打包进动态库。等扫描到func2.o时，发现需要show符号，但后面已经没有其他输入文件了，这个符号就被标记为未定义。
• 而反过来用gcc func2.o -o libfunc2.so -shared -fPIC libfunc1.a时：
  链接器先处理func2.o，立刻发现未定义的show符号，接着扫描后面的libfunc1.a，就会提取出func1.o来解析这个符号，最终show的实现被打包进了libfunc2.so，运行时自然能正常调用。

二、为什么编译时没有报错，却在运行时才出问题？ #

这是因为GCC编译动态库时，默认允许未定义符号延迟到运行时解析（等价于使用-z lazy选项）。链接器不会强制要求所有符号在编译阶段就完全解析，只要语法合法就能生成动态库。只有当程序运行时加载动态库，尝试调用未定义的符号时，才会触发“symbol lookup error”错误。

三、用动态库libfunc1.so依赖时为何也报错？ #

问题还是出在链接顺序上！你用的命令是gcc -o libfunc2.so -shared -fPIC -L. -lfunc1 -Wl,-rpath=. func2.o：
链接器先处理-lfunc1（也就是libfunc1.so），这时候还没扫描到func2.o，没有未定义的show符号，所以不会真正建立对libfunc1.so的依赖。等扫描到func2.o发现需要show时，后面已经没有其他库了，最终libfunc2.so里并没有记录对libfunc1.so的依赖，运行时系统找不到show的实现，自然报错。

正确的命令应该把func2.o放在-lfunc1前面：

gcc -o libfunc2.so -shared -fPIC func2.o -L. -lfunc1 -Wl,-rpath=.

这样链接器处理func2.o时发现需要show，接着就会链接libfunc1.so，并在libfunc2.so中记录依赖关系，运行时就能正确加载到show符号了。

备注：内容来源于stack exchange，提问作者Da Wang