使用g++静态链接库仍出现共享库加载错误的原因与解决

问题根源 #

你当前的链接命令虽然指定了./sdk/libNSomeLib.so.2.6，但这是动态库文件，链接器会执行动态链接而非静态嵌入。生成的可执行文件会依赖该库的soname（即libNSomeLib.so.2）——这是动态库的版本标识，Azure DevOps环境中没有这个soname对应的文件或搜索路径，因此运行时报错。

所谓的“静态链接”需要使用静态库文件（.a后缀），而非动态库.so，你之前的操作并没有真正实现静态链接，所以问题依然存在。

修复方案 #

方案一：修复动态链接依赖（无需静态库） #

如果不想切换到静态链接，可通过以下两种方式让运行时找到动态库：

• 临时设置库搜索路径：运行测试前指定LD_LIBRARY_PATH，告诉系统优先从./sdk目录找库：

  LD_LIBRARY_PATH=./sdk ./test
  

• 嵌入运行时路径到可执行文件：修改Makefile的链接命令，添加-Wl,-rpath=./sdk参数，让生成的test可执行文件记住库的搜索路径：

  test: app_test.o sdk.o
      g++ -L/usr/lib/x86_64-linux-gnu/ --coverage -o test app_test.o sdk.o -Wl,-rpath=./sdk ./sdk/libNSomeLib.so.2.6 -lboost_unit_test_framework
  

  这样Azure DevOps环境中运行./test时，会自动从./sdk目录加载libNSomeLib.so.2.6，无需额外配置。

方案二：真正实现静态链接（需要静态库） #

如果必须静态链接，需要具备该库的静态版本（.a文件）：

1. 确认你有libNSomeLib.a静态库文件，将其放入sdk目录；
2. 修改Makefile的链接命令，替换.so为.a，并添加-static参数强制静态链接：

   test: app_test.o sdk.o
       g++ -L/usr/lib/x86_64-linux-gnu/ --coverage -o test app_test.o sdk.o ./sdk/libNSomeLib.a -lboost_unit_test_framework -static
   

3. 如果没有.a文件，需要联系SDK提供商获取静态编译版本，或自行编译该库生成静态库。

本地运行正常的原因 #

本地环境中可能已经通过ldconfig配置了该库的系统级搜索路径，或LD_LIBRARY_PATH默认包含了库所在目录，甚至本地系统中存在libNSomeLib.so.2到libNSomeLib.so.2.6的符号链接，因此运行时能找到依赖库。

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