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

[Alexander Neundorf]

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.
>
> > and further down:
> > CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1
> >
> > 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.

But this RPATH would be patched out on make install.

> 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.

Alex