【问题标题】:Why does CMake links external library by relative path?为什么 CMake 通过相对路径链接外部库?
【发布时间】:2019-05-16 13:23:45
【问题描述】:

我在我的项目中使用外部共享库。我写了一个查找器,它成功定位了库并创建了依赖目标

...
set(_target MyLib)
add_library(${_target} UNKNOWN IMPORTED)
set_target_properties(${_target}
    PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${MYLIB_INCLUDE_DIRS}")
set_property(TARGET ${_target}
    APPEND PROPERTY IMPORTED_LOCATION "${MYLIB_LIBRARIES}")
...
message("${MYLIB_LIBRARIES}")
> /absolute/path/to/mylib.so

我使用这个库和其他一些库定义了一个目标

add_library(my_final_target SHARED
    mysource.cpp
    PRIVATE
    MyLib
    SomeOtherLib)

构建执行正常,但是当我查看 ldd 信息时,我看到了

ldd my_final_target.so
...
    some_other_lib.so -> /absolute/path/to/some_other_lib.so
    ../../../some/relative/path/mylib.so
...

mylib.so 和 some_other_lib.so 的 Finder 代码几乎相同。它们位于相邻文件夹中的同一磁盘上。 file 命令输出似乎也很合理:

ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, not stripped

我没有使用奇怪的编译标志或策略。可能是什么问题?

【问题讨论】:

    标签: c++ linux cmake shared-libraries


    【解决方案1】:

    听起来很奇怪,因为 mylib.so 中没有声明 SONAME

    objdump -p mylib.so | grep SONAME
    > 
    objdump -p some_other_lib.so | grep SONAME
    > SONAME        some_other_lib.so
    

    我用

    修复了 SONAME
    patchelf --set-soname mylib.so mylib.so
    

    现在好了:

    ldd my_final_target.so
    ...
        some_other_lib.so -> /absolute/path/to/some_other_lib.so
        mylib.so -> /absolute/path/to/mylib.so
    ...
    

    编辑:重复。见this question。我的 Google Fu 让我失望了……

    【讨论】:

    • 这太奇怪了
    • 确实如此。从来没有考虑过这种副作用。我花了 2 天时间才弄明白。
    猜你喜欢
    • 2018-10-15
    • 2011-04-28
    • 1970-01-01
    • 1970-01-01
    • 2012-04-22
    • 2021-09-17
    相关资源
    最近更新 更多