[CMake] new RPATH support questions

Alexander Neundorf a.neundorf-work at gmx.net
Mon Mar 6 18:07:25 EST 2006


Hi, 
 
> Von: Brad King <brad.king at kitware.com> 
>  
> Alexander Neundorf wrote: 
> > I just updated from current cvs.   
> >    
> > CMakeLists.txt:   
> >    
> > add_library(foo SHARED foo.c)   
> >    
> > add_executable(footest main.c)   
> >    
> > target_link_libraries(footest foor)   
> >    
> > install_targets(/bin footest)   
> > install_targets(/lib foo)   
> >    
> > This has the effect, that footest is initially linked with rpath to 
the  
> > library in the build dir, and when installed it is linked again but   
> > without RPATH. I thought it should be relinked to the install RPATH ?   
>  
> This is because no install rpath has been set and the default is empty.  
>   The INSTALL_RPATH target property is used to set the install tree  
> rpath.  See the documentation of SET_TARGET_PROPERTIES. 
>  
> > Besides that, AFAIK previous cmake version didn't relink during   
> > installation. Are you sure it is a good idea to change the default   
> > behaviour ?   
>  
> The old behavior left the build tree rpath in the installed binary 
which  
> is bad and was a common complaint.  The relink is actually preserving  
> old behavior of allowing one to run the binary from the build tree. 
>  
> > Does RPATH actually only exist for executables or also for shared  
> > libraries ? Does it have to be set for both or is it enough if it is 
set 
> > for the executables ?  
>  
> It may be set for both shared libraries and executables but only  
> executables (and perhaps loadable modules) really need it. 
>  
> > For KDE I plan the following:  
> >   
> > 1) CMAKE_SKIP_RPATH and create wrapper shell scripts which set  
> > LD_LIBRARY_PATH  
>  
> This should be left as a user option because it overrides all other  
> rpath settings and will leave out rpaths no matter what. 
>  
> > 2) COMPILE_WITH_INSTALL_RPATH and INSTALL_RPATH=  
> > ${CMAKE_INSTALL_PREFIX}/lib  
> > (for building releases)  
> >   
> > 3) COMPILE_WITH_INSTALL_RPATH and INSTALL_RPATH= 
${LIBRARY_OUTPUT_PATH; 
> > ${CMAKE_INSTALL_PREFIX}/lib  
> > (for developers, so that it runs also from the builddir)  
> >   
> > Do you think this is sensible ?  
> >   
> > I think relinking is not a good option for KDE, since this will take  
> > really a lot of time.  
>  
> This is a topic for the KDE list since it is a decision for that 
project  
> and not CMake. 
 
Ok, I tested now the following: 
 
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) 
set(CMAKE_SKIP_BUILD_RPATH TRUE) 
 
set(CMAKE_INSTALL_RPATH ${LIBRARY_OUTPUT_PATH}/${CMAKE_CFG_INTDIR}/  
                        ${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}) 
 
Which gives

CMAKE_INSTALL_RPATH=/home/alex/src/kde4-svn/kdelibs-build/lib/.:/opt/kde4/lib

as expected.  
When linking, this is then used for RPATH. 
This should have the effect that it can be installed without relinking 
and that it has RPATH both to the build dir and to the install dir set. 
 
Before these changes, there was also the directory to the Qt libs 
(/usr/lib/qt4/lib) used for the RPATH. This is gone now, I didn't expect 
this. I expected that only the paths to the libraries compiled within 
this project would be removed by setting CMAKE_SKIP_BUILD_RPATH to true. 
 
Is this a bug or a feature ? If it's a feature, why has it been 
implemented this way ? 
 
Bye 
Alex 
 

-- 
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net


More information about the CMake mailing list