1

I use in my project external shared library. I wrote a finder which successfully locates library and creates dependency target

...
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

I defined a target using this library and some others

add_library(my_final_target SHARED
    mysource.cpp
    PRIVATE
    MyLib
    SomeOtherLib)

Build performs OK, but when I look at ldd info I see

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

Finder code for mylib.so and some_other_lib.so is nearly identical. They are located on the same disk in neighbor folders. file command output also seems reasonable:

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

I use no strange compilation flags or policies. What the problem could be?

1 Answers1

2

As strange as it sounds it was because mylib.so had no SONAME declared in it

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

I fixed SONAME with

patchelf --set-soname mylib.so mylib.so

and now it's fine:

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

EDIT: Duplicate. See this question. My Google Fu failed me...