CMake构建后可执行文件缺失Leptonica库完整路径问题排查

从你提供的信息来看，这个跨平台的路径识别问题核心矛盾非常明确：可执行文件的RUNPATH已经包含了Leptonica库的正确目录，但动态链接器依然找不到libleptonica.so.5.3.0，而同目录下的Tesseract等其他库却能正常被识别。结合Leptonica的导入目标配置文件和库文件结构，我可以确定根本原因如下：

核心原因：Leptonica导入目标的SONAME配置导致链接行为差异 #

对比Tesseract和Leptonica的导入目标设置，你会发现Leptonica的LeptonicaTargets-release.cmake中明确设置了IMPORTED_SONAME_RELEASE "libleptonica.so.5.3.0"，而Tesseract的导入目标大概率没有这个设置（或者设置了IMPORTED_NO_SONAME ON）。

当CMake链接带有IMPORTED_SONAME属性的导入目标时，它只会将SONAME文件名（而非完整库路径）写入可执行文件的动态依赖表中。动态链接器运行时会在RUNPATH指定的目录下搜索这个SONAME对应的文件，但这里存在潜在的匹配问题：

1. 你的Leptonica库目录中，libleptonica.so.5.3.0是指向实际库文件libleptonica.so.1.77.0的软链接
2. 虽然RUNPATH包含了该目录，但动态链接器在搜索时，可能因为系统层面的优先级规则（比如先搜索系统库目录），或者软链接的解析逻辑，导致无法匹配到目标文件

而Tesseract这类没有设置IMPORTED_SONAME的库，CMake会直接将完整库路径写入可执行文件的依赖中，动态链接器无需搜索，直接使用指定路径，因此不会出现问题。

验证与解决步骤 #

1. 确认库的实际SONAME是否匹配 #

首先运行以下命令，检查Leptonica实际库文件的SONAME是否和导入目标中的设置一致：

readelf -d libs/3rdparty/leptonica/lib/libleptonica.so.1.77.0 | grep SONAME

如果输出不是SONAME Library soname: [libleptonica.so.5.3.0]，说明Leptonica编译时的SONAME配置错误，需要重新编译Leptonica并确保SONAME设置正确。

2. 强制CMake使用完整库路径链接 #

如果SONAME是正确的，那么可以通过修改Leptonica的导入目标属性，让CMake在链接时写入完整库路径而非SONAME。在你的CMakeLists.txt中，find_package(Leptonica REQUIRED)之后添加以下代码：

# 针对Release配置，禁用SONAME，强制使用完整路径链接
set_target_properties(leptonica PROPERTIES
  IMPORTED_NO_SONAME_RELEASE ON
)

# 如果需要Debug配置，也可以添加对应的设置
# set_target_properties(leptonica PROPERTIES
#   IMPORTED_NO_SONAME_DEBUG ON
# )

这个设置会覆盖Leptonica导入目标中的IMPORTED_SONAME配置，让CMake链接时直接使用IMPORTED_LOCATION_RELEASE中指定的完整库路径，动态链接器运行时会直接加载该路径下的库，无需搜索SONAME。

3. 确认RPATH相关CMake变量的正确设置 #

确保你的CMake配置中以下变量设置正确，避免RPATH配置遗漏：

# 构建时就使用INSTALL_RPATH（不需要等到安装后）
set(CMAKE_BUILD_WITH_INSTALL_RPATH ON)

# 设置安装后的RPATH，包含所有第三方库目录
set(CMAKE_INSTALL_RPATH "${CMAKE_CURRENT_SOURCE_DIR}/libs/3rdparty/leptonica/lib;${CMAKE_CURRENT_SOURCE_DIR}/libs/3rdparty/tesseract/lib")

# 自动将链接时用到的库路径添加到RPATH
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH ON)

这些变量要确保在add_executable之前设置，才能正确应用到你的测试可执行目标上。

总结 #

这个问题本质是CMake导入目标的SONAME配置与动态链接器搜索行为的不匹配导致的，通过禁用Leptonica导入目标的SONAME属性，强制使用完整路径链接，就能解决这个跨平台的路径识别问题，无需依赖LD_LIBRARY_PATH环境变量。

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