如何在CMake中实现LD_LIBRARY_PATH的效果？相关疑问解析

一、为什么link_directories()解决不了运行时的库加载错误？ #

link_directories()是CMake专门用于编译链接阶段的指令，它的作用是告诉链接器（如ld）在链接生成可执行文件时，去哪里查找需要的共享库（.so），确保链接步骤能顺利完成。但它不会对生成的可执行文件的运行时属性做任何修改。

程序运行时，负责加载共享库的是动态链接器（如ld-linux.so.2），它会按照固定规则搜索库文件：优先查找可执行文件内部记录的rpath路径，再去系统标准路径（/lib、/usr/lib等）。而link_directories()设置的路径并没有被写入可执行文件的rpath，所以动态链接器在运行时找不到对应的库，就会抛出error while loading shared libraries错误。

二、link_directories()与LD_LIBRARY_PATH的核心区别 #

• 作用阶段不同

  • link_directories()：仅作用于编译链接阶段，帮助链接器找到待链接的共享库，完成可执行文件的生成。
  • LD_LIBRARY_PATH：作用于程序运行阶段，是动态链接器查找共享库的额外搜索路径，优先级高于系统默认路径（但低于可执行文件的rpath）。

• 生效范围不同

  • link_directories()：是CMake项目的构建配置，只对当前项目的构建过程生效，不会影响系统全局或其他程序的运行。
  • LD_LIBRARY_PATH：是系统环境变量，设置后会影响当前shell会话中所有运行的程序的动态库搜索路径，属于会话级的全局配置。

• 实现机制不同

  • link_directories()：本质是给链接器传递-L参数，仅指导链接阶段的库查找逻辑，不会修改生成的可执行文件。
  • LD_LIBRARY_PATH：是动态链接器的环境变量，动态链接器加载共享库时会先遍历该变量中的路径，再去系统默认路径查找。

三、补充：通过CMake解决运行时库加载的替代方案 #

如果不想依赖LD_LIBRARY_PATH，可以通过CMake配置可执行文件的rpath，让动态链接器在运行时自动找到库：

• 针对构建后的临时运行场景：

  set(CMAKE_BUILD_RPATH "${CMAKE_CURRENT_BINARY_DIR}/lib")
  

• 针对安装后的正式运行场景：

  set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
  

• 针对单个目标单独设置：

  target_link_options(your_executable PRIVATE "-Wl,-rpath,${CMAKE_CURRENT_SOURCE_DIR}/lib")
  

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