[CMake] embedded path in shared library linked into another shared library

Michael Hertling mhertling at online.de
Wed Apr 13 21:06:52 EDT 2011


On 04/13/2011 08:52 PM, Alexander Neundorf wrote:
> On Tuesday 12 April 2011, Michael Hertling wrote:
>> On 04/11/2011 11:10 PM, David Aiken wrote:
>>> That didn't work for me.. I've got it simplified down to:
>>> SET(CMAKE_SKIP_RPATH TRUE)
>>> and in the CMakeCache.txt I see:
>>> CMAKE_SKIP_RPATH:BOOL=NO
>>
>> That's not surprising as your SET() command doesn't write to the cache.
>> It's the CMAKE_SKIP_RPATH variable's value in the current scope which
>> is - should be - crucial for dropping the RPATH settings, AFAIK.
>>
>>> I'm using the codeblocks unix makefile target. The rpath is present in
>>> both the build and install shared library.
>>
>> With the UnixMakefile generator, I can see the following CMakeLists.txt
>>
>> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
>> PROJECT(RPATH C)
>> SET(CMAKE_VERBOSE_MAKEFILE ON)
>> SET(CMAKE_SKIP_RPATH TRUE)
>> FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
>> ADD_LIBRARY(f SHARED f.c)
>> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
>> ADD_EXECUTABLE(main main.c)
>> TARGET_LINK_LIBRARIES(main f)
>>
>> produce the following command line to link:
>>
>> .../gcc CMakeFiles/main.dir/main.c.o -o main -rdynamic libf.so
>>
>> I.e., no RPATH for the executable.
> 
> Yes, but this is because you did not link against a library with a path. So 
> you don't get any RPATH.
> TARGET_LINK_LIBRARIES(main /opt/foo/libf.so)
> would give you an RPATH in this command.

AFAICS, that's not true. Look at the following CMakeLists.txt:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(RPATH C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(CMAKE_SKIP_RPATH TRUE)
FILE(WRITE /dev/shm/libf.so "")
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main /dev/shm/libf.so)

The command which links the executable is

.../gcc CMakeFiles/main.dir/main.c.o -o main -rdynamic -L/dev/shm -lf

i.e. still no RPATH for the executable, although the command fails due
to the invalid empty libf.so, of course. Specifying a full path for a
library in TARGET_LINK_LIBRARIES() does not overwrite RPATH settings;
in particular, the CMAKE_SKIP_RPATH set to TRUE keeps being effective.
When linking against a valid library, however, you get the library's
full path on the link command line instead of the -L/-l combination
unless the library is placed in a well-known system directory, but
still no RPATH as long as CMAKE_SKIP_RPATH is set to TRUE.

>> Does the above-noted CMakeLists.txt actually produce different results
>> w.r.t. the RPATHs when using the CodeBlocksUnixMakefiles generator?
> 
> Should be impossible, because the CodeBlocks generator simply generates the 
> normal makefiles, and additionally the codeblocks xml project files.

This is why I suppose that the OP's issue is caused by something else.

Regards,

Michael


More information about the CMake mailing list