[CMake] library path stripping

Andreas Naumann Andreas-Naumann at gmx.net
Thu Jun 9 01:13:35 EDT 2011


Am 08.06.2011 20:43, schrieb Andreas Pakulat:
> On 08.06.11 20:00:54, Andreas Naumann wrote:
>    
>> 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
>>      
> I can reproduce this here with CMake 2.8.4.
>
> And before someone else asks (since I thought that might be the error),
> the envvar is really "LIBRARY_PATH", i.e. not LD_LIBRARY_PATH.
>
> The strange thing is that there's no occurrence of this specific string
> anywhere in the cmake sources. There are all kinds of occurrence of
> LD_... or CMAKE_... but no string matching just LIBRARY_PATH. So its
> unclear why CMake respects that envvar.
>
> Andreas
>
> _______________________________________________
> 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
>
>    

The problem is related to the compiler, not to the linker. The 
gcc-documentation
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Environment-Variables.html#Environment-Variables
says:

LIBRARY_PATH
The value of LIBRARY_PATH is a colon-separated list of directories, much 
like PATH. When configured as a native compiler, GCC tries the 
directories thus specified when searching for special linker files, if 
it can't find them using GCC_EXEC_PREFIX. Linking using GCC also uses 
these directories when searching for ordinary libraries for the -l 
option (but directories specified with -L come first).

CMake seems to ask the compiler for implicitly used link directories and 
removes each path in this list from the libraries in the directories.
Because this information comes from the compiler, cmake cannot 
distinguish between working and not working directories.
My question is now, why does cmake remove the paths? If the use 
specifies a library with full path, he wants EXACTLY this library.

Currently, we print a warning, if the variable LIBRARY_PATH is set in 
the environment.

Andreas


More information about the CMake mailing list