Почему CMake связывает внешнюю библиотеку относительным путем? - PullRequest
Новая
       14

Почему CMake связывает внешнюю библиотеку относительным путем?

1 голос
/ 16 мая 2019

Я использую в своем проекте внешнюю общую библиотеку. Я написал искатель, который успешно находит библиотеку и создает цель зависимости 

...
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 практически идентичен. Они расположены на одном диске в соседних папках. file вывод команды также кажется разумным: 

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

Я не использую странные флаги или политики компиляции. В чем может быть проблема?

1 Ответ

2 голосов
/ 16 мая 2019

Как ни странно, это было потому, что в 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
...

РЕДАКТИРОВАТЬ: Дублировать.См. этот вопрос .Мой Google Фу подвел меня ...

...