ld查找共享对象二级依赖的机制及链接路径问题咨询

问题场景 #

链接共享库libfoo.so（该库依赖libbar.so）时，编译直接依赖libfoo.so的可执行文件，使用如下编译选项：

-L<location of libbar.so> -lfoo

但链接器ld会优先拾取系统路径中的libbar.so，导致符号集不匹配，出现未定义引用错误。而将命令修改为：

-L<location of libbar.so> -lfoo -lbar

ld就能找到指定位置的正确libbar.so。

核心疑问解答 #

1. 这是预期行为吗？ #

是的，这是ld的预期行为，根源在于链接器的库查找逻辑：

• 当你在命令行指定-lfoo时，链接器会找到libfoo.so并读取它的依赖列表，但对于列表中的二级依赖libbar.so，链接器默认只会搜索标准系统库路径，不会自动继承命令行中前面的-L路径。
• 只有当你在命令行显式通过-lbar指定库时，前面的-L路径才会被用于该库的查找，因此修改后的命令能找到正确的libbar.so。

2. 无需显式链接的解决方法 #

以下几种方式可以让ld自动定位指定位置的二级依赖：

• 给libfoo.so嵌入rpath信息
  在编译libfoo.so时，通过-rpath选项将libbar.so的路径写入动态链接信息：

  gcc -shared -o libfoo.so foo.o -L<location of libbar.so> -lbar -Wl,-rpath=<location of libbar.so>
  

  后续编译可执行文件时，ld加载libfoo.so后会自动从rpath指定的路径查找libbar.so，无需额外配置。

• 临时设置LD_LIBRARY_PATH环境变量
  在编译或运行前，设置环境变量让动态链接器优先搜索目标路径：

  export LD_LIBRARY_PATH=<location of libbar.so>:$LD_LIBRARY_PATH
  

  该方式仅临时生效，适合测试场景，不推荐生产环境使用。

• 修改系统默认库搜索路径
  若需长期生效，可将libbar.so的路径加入系统默认搜索配置：

  1. 在/etc/ld.so.conf.d/目录下新建配置文件（如custom-libs.conf），写入libbar.so的所在路径
  2. 执行ldconfig命令更新链接器缓存
     该方式需要管理员权限，会全局生效。

内容的提问来源于stack exchange，提问作者Ton van den Heuvel