Ubuntu22编译的.so库在Ubuntu24加载失败问题求助

1. GCC版本差异导致符号导出行为变化
   GCC 11（Ubuntu22）与GCC 13（Ubuntu24）在符号可见性的默认处理上存在差异。你编译进mylib.so的_TIFFwarningHandler符号，在GCC11编译时未被正确导出到动态符号表——可能是libtiff源码中该符号的声明未显式标记导出，而GCC11默认隐藏了这类符号，GCC13则默认导出了该符号。

2. Ubuntu24动态链接器解析逻辑更严格
   Ubuntu24的ld.so动态链接器采用了更严格的符号解析规则。当mylib.so中的_TIFFwarningHandler未出现在动态符号表时，链接器会判定它为外部符号，尝试从系统库中查找。但Ubuntu24系统自带的libtiff版本可能已移除或重命名了该符号，最终导致加载失败。

而Ubuntu24编译的mylib.so能正常运行，是因为GCC13正确将该符号导出到动态符号表，链接器直接从mylib.so内部找到符号，无需依赖系统库。替换该库后，Ubuntu22编译的可执行文件能运行，也印证了问题仅出在Ubuntu22编译的mylib.so的符号导出上。

以下方法可让Ubuntu22编译的程序兼容Ubuntu24：

• 显式导出目标符号
  在libtiff源码中_TIFFwarningHandler的声明处添加__attribute__((visibility("default")))属性，强制该符号被导出到动态符号表：

  __attribute__((visibility("default")))
  void _TIFFwarningHandler(const char* module, const char* fmt, va_list ap);
  

• 调整链接选项强制导出全局符号
  在编译mylib.so的链接阶段添加-Wl,--export-dynamic参数，强制导出所有全局符号（代价是库文件体积略有增大，但能彻底解决符号缺失问题）：

  gcc -shared -o mylib.so obj_files.o -Wl,--export-dynamic
  

• 验证符号导出状态
  编译完成后，用nm命令检查符号是否存在于动态符号表：

  nm -D mylib.so | grep _TIFFwarningHandler
  

  若输出包含T标记（表示全局代码符号），说明符号已成功导出；若无输出，需重新调整编译/链接选项。

• 静态编译libtiff到mylib.so
  将libtiff的目标文件打包为静态库，再链接到mylib.so中，确保所有符号都被包含在库内：

  # 将libtiff目标文件打包成静态库
  ar rcs libtiff.a tiff_obj_files.o
  # 链接静态库到mylib.so
  gcc -shared -o mylib.so main_obj_files.o libtiff.a
  

内容的提问来源于stack exchange，提问作者RED SOFT ADAIR