Astra Linux下库依赖报错：libmy.so.1未找到及符号引用未定义

问题核心分析 #

你遇到的问题本质是动态库依赖链的SONAME不匹配、符号未正确导出或编译链接参数缺失导致的，虽然core.so能正常被识别，但my.so的配置不符合Linux动态链接器的规则。

排查与解决步骤 #

1. 检查动态库的SONAME配置 #

Linux下动态库的SONAME（共享对象名称）是链接器识别依赖的关键，这是Windows平台没有的机制：

• 查看manager.so声明的依赖库：

  readelf -d libmanager.so | grep NEEDED
  

  输出里应该能看到libcore.so和libmy.so.1。
• 查看my.so的SONAME：

  readelf -d libmy.so | grep SONAME
  

  如果输出为空，或者不是libmy.so.1，说明my.so的SONAME未正确设置。

解决方法：
重新编译my.so时指定SONAME，并创建对应版本的软链接：

# 编译my.so.1并设置SONAME
g++ -shared -fPIC -o libmy.so.1 my.cpp -Wl,-soname,libmy.so.1
# 创建软链接供编译时引用
ln -s libmy.so.1 libmy.so

2. 验证my.so的符号可见性 #

undefined reference to my::my()说明链接器找不到该构造函数的符号，这是Linux符号隐藏机制导致的（Windows默认导出所有符号，Linux若用-fvisibility=hidden会隐藏未显式导出的符号）：

• 检查my.so中是否存在该符号：

  nm -D libmy.so | grep "my::my"
  

  正常输出应该带T标记（全局可见的代码符号），如果无输出或标记为U（未定义），说明符号未导出。

解决方法：

• 方法一：在my类构造函数声明前显式添加导出属性：

  class my {
  public:
      __attribute__((visibility("default")))
      my();
      // 其他成员...
  };
  

• 方法二：编译my.so时去掉-fvisibility=hidden参数（如果之前添加过）。

3. 修正编译链接的rpath参数 #

Linux动态链接器默认不会从程序/库所在目录加载依赖，需通过-rpath参数将依赖路径嵌入到库或程序中：

• 重新编译manager.so时添加-rpath='$ORIGIN'（$ORIGIN表示当前库所在目录）：

  g++ -shared -fPIC -o libmanager.so manager.cpp -L./ -lcore -lmy -Wl,-rpath='$ORIGIN'
  

• 编译主程序时同样添加该参数：

  g++ -o main main.cpp -L./ -lmanager -Wl,-rpath='$ORIGIN'
  

4. 验证依赖链 #

完成上述步骤后，用以下命令验证manager.so的依赖是否能被正确找到：

ldd libmanager.so

如果输出中libmy.so.1显示为正确路径，说明依赖问题已解决。

为什么core.so没问题？ #

大概率是core.so的SONAME配置正确、符号完全导出，且编译manager.so时的参数已经正确处理了core.so的依赖（比如core.so在系统默认路径下，或者编译时已通过-rpath嵌入路径），所以链接器能正常识别。

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