[CMake] library path stripping

[Andreas Naumann]

Am 08.06.2011 15:02, schrieb Eric Noulard:
> 2011/6/8 Andreas Naumann<Andreas-Naumann at gmx.net>:
>    
>> Am 08.06.2011 11:56, schrieb Eric Noulard:
>>      
>>> 2011/6/8 Andreas Naumann<Andreas-Naumann at gmx.net>:
>>>
>>>        
>>>> Hi @all,
>>>>
>>>> I have some problem with the library usage in cmake.
>>>>
>>>> It seems to me, that cmake removes the full path of the library, if the
>>>> path
>>>> is in the environment variable LIBRARY_PATH.
>>>> This behaviour cause problems at our system, such that the linker links
>>>> against the wrong library.
>>>>
>>>> Is there an option to avoid this splitting?
>>>>
>>>>          
>>> Did you read that:
>>> http://www.cmake.org/Wiki/CMake_RPATH_handling
>>>
>>> Which version of CMake are you using?
>>> On which system ?
>>>
>>>
>>>
>>>        
>> We are using version 2.8.2 and 2.8.4 on Debian and Suse Linux.
>>
>> I've read the hints on RPATH handling, but there it is said, that:
>> "By default if you don't change any RPATH related settings, CMake will link
>> the executables and shared libraries with full RPATH to all used libraries
>> in the build tree"
>>      
> Yes.
> And you did not mention it but the probleme you have occurs when using
> the executable **directly from the build dir** right?
>    
what do you mean with "using"? I cannot even link the executable, 
because cmake removes the path from the library without adding the 
directory to the library directories.

>    
>> This means, if I don't set anything related to RPATH, cmake should not strip
>> the path from the library, should it?
>>      
> No it shoudn't for the binary in the buitd tree but...
> if you do "make install" the installed binaries will have no RPATH unless
> you set
>
> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
>
> # add the automatically determined parts of the RPATH
> # which point to directories outside the build tree to the install RPATH
> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
>
>    
I don't even want to install, just build and use.
>> I played with the example and it was a bit hard to understand, when the path
>> is stripped from the library.
>> The problem arises before linking the executable.
>>      
> This is a different issue.
> Could you copy/paste the
>
> add_executable
> and
> target_link_libraries
>
> statement you use for the offending executable?
>
>    
simple:
project("test")

cmake_minimum_required(VERSION 2.8)
set(MYLIB /home/andreas/cmake_test/lib/libfoo.so)
add_executable(foo_exec test.cc)
target_link_libraries(foo_exec ${MYLIB})

So the executable gets the full name and the example works, if the 
environment variable library_path is not set to 
/home/andreas/cmake_test/lib. The link command is:

/usr/bin/c++      CMakeFiles/foo_exec.dir/test.cc.o  -o foo_exec 
-rdynamic /home/andreas/cmake_test/lib/libfoo.so 
-Wl,-rpath,/home/andreas/cmake_test/lib

If I set LIBRARY_PATH to /home/andreas/cmake_test/lib, the directory is 
stripped and the link-command gets:

/usr/bin/c++      CMakeFiles/foo_exec.dir/test.cc.o  -o foo_exec 
-rdynamic -lfoo


>> We link to a library, which exists in two different directories:
>> /usr/lib64
>> and
>> somewhere/lib/
>>      
> This should be resolved by YOU inside CMakeLists.txt by
>
> target_link_libraries(exename /path/to/appropriate/lib/lbname.so)
>
> the
> /path/to/appropriate/lib/lbname.so could be the result of an appropriate
> find_library
> call.
>
>    
>> At the same time, the environment variable LIBRARY_PATH is set to
>> somewhere/lib. In this case, cmake removes the path from the library name,
>> but does not append it as -L to the linker search paths.
>> Now it is up to the linker to choose the right library, which is really bad!
>> In our case (gcc 4.1.2 on Suse) it selects the wrong library.
>>
>> Is there any possibility to avoid this "environmentvariable dependent"
>> splitting?
>>      
> Yes full RPATH should be the solution.
>
>
>