嘿，这个问题我之前帮不少开发者踩过坑，本质是**RPATH（运行时库搜索路径）**的配置问题，我给你拆解下原因和修复步骤：

为什么会出现这个问题？ #

当你用CMake链接IMPORTED共享库时，如果只设置了IMPORTED_LOCATION指向开发机上的绝对路径，CMake会直接把这个开发机的路径硬编码到可执行文件的RPATH中。而RPATH的搜索优先级比系统通过ld.so.conf.d配置的默认路径高——到了测试机上，系统会先尝试找开发机的那个不存在的路径，自然就报"not found"，哪怕你已经把库放到了测试机的正确路径里也没用。

修复方法 #

1. 给IMPORTED库设置SONAME属性（推荐，从根源解决） #

对于IMPORTED共享库，你需要同时设置IMPORTED_SONAME属性，告诉CMake用库的SONAME（也就是不带路径的库名，比如libxxx.so）来链接，而不是硬编码开发机的绝对路径。示例代码如下：

# 声明IMPORTED共享库
add_library(xxx SHARED IMPORTED)

# 配置属性：IMPORTED_LOCATION是开发机上的库路径（编译阶段用），IMPORTED_SONAME是库的逻辑名称
set_target_properties(xxx PROPERTIES
    IMPORTED_LOCATION "/path/on-dev-machine/to/libxxx.so"
    IMPORTED_SONAME "libxxx.so"
)

# 链接到你的目标可执行文件/库
target_link_libraries(your_target PRIVATE xxx)

这样编译出来的可执行文件会用libxxx.so来引用库，到测试机上就会去系统默认路径（包括你在ld.so.conf.d里配置的路径）查找。

2. 修改已编译可执行文件的RPATH（应急方案） #

如果已经编译好了可执行文件，不想重新编译的话，可以用chrpath工具修改RPATH，去掉硬编码的开发机路径：

# 先查看当前可执行文件的RPATH
chrpath -l your_executable

# 删除硬编码的RPATH，让系统使用默认搜索路径
chrpath -d your_executable

# 或者手动设置空的RPATH（效果和删除一样）
chrpath -r "" your_executable

3. 确保测试机的库配置生效 #

最后别忘了在测试机上做这两步：

• 把libxxx.so放到你在/etc/ld.so.conf.d中配置的路径下（比如/usr/local/lib）
• 执行sudo ldconfig刷新系统库缓存，让系统识别到新安装的库

补充提醒 #

为什么你加了ld.so.conf.d还是没用？记住这个优先级：RPATH > LD_LIBRARY_PATH > 系统默认路径（ld.so.conf.d配置的路径）。只要可执行文件里有硬编码的RPATH，系统就会优先找那个路径，所以核心是让CMake不要把开发机的绝对路径写到RPATH里，而是用SONAME来引用库。

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