Bill Hoffman wrote: > So, it must be that the library is built with no soname. Brad will be > back in a few days, and should have a better idea of how to fix it.
This is probably the problem. You can confirm this by running readelf -d /home/kchang/sandbox/thost/thostmduserapi.so |grep SONAME If a line like this: 0x000000000000000e (SONAME) Library soname: [...] does not appear then there is no soname. > For now, you can do one of these: > > 1. rename the library to have lib in front of it libthostmduserapi.so ...or create a symlink to it with that name and give the full path to the symlink to CMake. > 2. Rebuild thostmduserapi.so with an soname This is the best fix. Shared libraries should always have the soname field set because that is how the runtime linker is supposed to locate the library. I would be interested in an explanation from the authors of that library as to why it has no 'lib' prefix or soname. > 3. Add this to your CMakeLists.txt file: > > set(CMAKE_PLATFORM_USES_PATH_WHEN_NO_SONAME FALSE) > > before the target_link_library call. But, that might have some bad rpath > information. It will work but the resulting binary will only run on the machine where it is built and always use thostmduserapi.so from that full path. 4.) You can also tell CMake to use the full path by creating an IMPORTED target for the library: add_library(thostmduserapi SHARED IMPORTED) set_property(TARGET thostmduserapi PROPERTY IMPORTED_LOCATION /home/kchang/sandbox/thost/thostmduserapi.so) target_link_libraries(myexe thostmduserapi) Now CMake will use the full path, but the restrictions on running the result will be the same as option #3 above. -Brad _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake