[CMake] library path stripping

Andreas Naumann Andreas-Naumann at gmx.net
Wed Jun 8 08:27:46 EDT 2011


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"

This means, if I don't set anything related to RPATH, cmake should not 
strip the path from the library, should it?

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. We link to a library, 
which exists in two different directories:
/usr/lib64
and
somewhere/lib/

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?




More information about the CMake mailing list