[CMake] TARGET_LINK_LIBRARIES with full path libraries

[Volker Pilipp]

On Wed, Sep 17, 2014 at 12:58 PM, Nils Gladitz <nilsgladitz at gmail.com>
wrote:

> On 09/17/2014 12:29 PM, Volker Pilipp wrote:
>
>> I have encountered the following problem with cmake 3.0.1.
>> Under certain circumstances TARGET_LINK_LIBRARIES replaces
>> "/path/to/libXXX.so" by "-lXXX". The problem occurred when I used a
>> non-standard compiler at /opt/XXX/bin/g++ and added the library
>> /opt/XXX/lib/libXXX.so to TARGET_LINK_LIBRARIES.
>> In particular CMakeLists.txt reads:
>>
>> "SET(CMAKE_CXX_COMPILER /opt/XXX/bin/g++)
>> CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0)
>> PROJECT(XXX)
>> add_executable(xxx xxx.cpp)
>> target_link_libraries(xxx /opt/XXX/lib/libXXX.so)"
>>
>> When running make VERBOSE=1 produces output like
>>
>> /opt/XXX/bin/g++ (...) -lXXX
>>
>> which is not the same as
>> /opt/XXX/bin/g++ (...) /opt/XXX/lib/libXXX.so
>>
>
> I think CMake reverts to linking by name if either the library is in an
> implicit linker directory (e.g. a directory the linker searches by default)
> or if the shared library does not have an SONAME.
>
> Which library does -lXXX resolve to?
> e.g. why aren't the two command lines equivalent for you?
>

-lXXX stands in the actual case for libcurl.so. I have both
/usr/lib4/libcurl.so.3 and /opt/XXX/llib/libcurl.so.4 installed and I want
my program to be linked against the latter one.


>
> Specifically which library does the linker (ld) pick up;
> not the runtime loader (ld.so).


An ldd on the executable produces
libcurl.so.3 => /usr/lib64/libcurl.so.3

Depending on LD_LIBRARY_PATH, (or rpath,...)  I would have expected
something like this
libcurl.so.4 => NOT FOUND
or
libcurl.so.4 => /opt/XXX/lib/libcurl.so.4

Volker




>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20140917/09c4e079/attachment.html>