C++ CMake、链接目录和多个Boost安装

我在没有root权限的服务器上工作。我有一个简单的命令行应用程序，链接到OpenCV和Boost，我使用的是cmake 2.8.12。/usr/lib64中有旧的boost库，但我想使用新的boost库，可以使用环境模块加载。CMakeLists.txt文件如下所示：

cmake_minimum_required(VERSION 2.8.12)

find_package(Boost 1.55.0 REQUIRED COMPONENTS program_options system thread)
find_package(OpenCV REQUIRED)

message("Boost dirs: ${Boost_LIBRARY_DIRS} ${Boost_INCLUDE_DIRS}")
message("Boost libraries ${Boost_LIBRARIES}")

include_directories(${OpenCV_INCLUDE_DIRS} ${Boost_INCLUDE_DIRS})

# set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -L${Boost_LIBRARY_DIRS}")

add_executable(tile_images src/tile_images.cpp)
target_link_libraries(tile_images ${OpenCV_LIBRARIES} ${Boost_LIBRARIES} )

这些消息将打印到正确库的完整路径：

Boost目录：/cm/shared/apps/Boost/1.56/lib /cm/shared/apps/boost/1.56/include

增强库 /cm/shared/apps/boost/1.56/lib/libboost_program_options.so/cm/shared/apps/boost/1.56/lib/libboost_system.so/cm/shared/apps/boost/1.56/lib/libboost_thread.so

链接时出现问题，cmake生成以下对c++的调用：

/usr/bin/c++cmakfiles/tile_images.dir/src/tile_images.cpp.o -o tile_images-rdynamic/cm/shared/apps/opencv/2.4.9/lib/libopencv_videostab.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_video.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_ts.a /cm/shared/apps/opencv/2.4.9/lib/libopencv_superres.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_-stitching.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_photo.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_ocl.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_objdetect.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_nonfree.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_ml.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_legacy.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_imgproc.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_highgui.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_gpu.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_flann.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_功能2d.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_core.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_contrib.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_calib3d.so.2.4.9 -lboost_程序选项-lboost_系统-lboost_线程-ldl-lm-lpthread-lrt/cm/shared/apps/opencv/2.4.9/lib/libopencv_nonfree.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_ocl.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_gpu.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_photo.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_objdetect.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_legacy.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_video.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_ml.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_calib3d.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_功能2d.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_highgui.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_imgproc.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_flann.so.2.4.9 /cm/shared/apps/opencv/2.4.9/lib/libopencv_core.so.2.4.9

请注意boost库的绝对路径是如何被剥离的，并且没有使用-L标志将其包括在内。然后我得到以下警告，暗示链接器正在/usr/lib64中安装另一个较旧的boost

/usr/bin/ld:警告：libboost_system.so.1.56.0，需要 /cm/shared/apps/boost/1.56/lib/libboost_thread.so可能与 libu系统

链接失败，出现一长串错误，可能是因为使用了旧的Boost库，但代码是用新的Boost头构建的

如果我将以下内容添加到CMakeLists.txt：

设置（CMAKE_CXX_标志“${CMAKE_CXX_标志}-L${Boost_LIBRARY_DIRS}”）

---

然后代码链接就没有问题了。我花了一些时间进行研究，但到目前为止，对于如何让CMake包含-L标志或如何阻止它从boost库中剥离绝对路径，我还是一片空白。任何帮助都将不胜感激

我相信这在：

集合（Boost\u REALPATH ON）

中有解释

Boost_REALPATH-设置为“开”以解析已发现的符号链接 库来帮助打包。例如 “系统”组件库可解析为 “/usr/lib/libboost_system.so.1.42.0”而不是 “/usr/lib/libboost_system.so”。这是不可能的 影响链接，除非 用户需要这些信息

---

您是否检查了中的

Boost\u REALPATH

和

Boost\u DEBUG

？谢谢，将Boost\u REALPATH设置为ON似乎可以解决此问题。我不确定我是否完全理解为什么这不是默认行为。你能添加一个答案吗，然后我会接受它。实际上，我添加了它作为一个答案，然后我看到一句话“这不影响链接，不应该启用，除非用户需要此信息”，并删除了它。我现在很困惑。是的，我也很困惑。当我在运行find_包之后打印${Boost_LIBRARIES}（没有将Boost_REALPATH设置为ON）时，将打印到库的正确完整路径。但是，在运行make时，在调用C++时，只有库名出现。这种行为似乎很意外，我仍然不明白为什么它是默认的……我想说，这是您需要手动添加“Boost\u LIBRARY\u DIRS”的预期行为。您可以使用

链接目录（${Boost\u LIBRARY\u DIRS}）

更方便地实现这一点。

Boost\u REALPATH

有帮助的原因与搜索顺序有关。通过将库名称调整为其中包含版本的名称，gcc现在可以找到新库，尽管它在搜索顺序中较低，因为它只存在于其中。谢谢，这解决了我的问题，尽管我不明白为什么，特别是考虑到最后一句话（见上面的评论）：“这不会影响链接，除非用户需要此信息，否则不应启用链接。”