Re: [Openrti-devel] CMake relinking produces broken rpath for libOpenRTI-NG.so

[Hamza A. <ham...@li...>]

Hello :)
________________________________
> From: Mat...@gm... 
> To: ope...@li... 
> CC: ham...@li... 
> Subject: Re: [Openrti-devel] CMake relinking produces broken rpath for  
> libOpenRTI-NG.so 
> Date: Thu, 28 May 2015 10:02:37 +0200 
>  
>  
>  
>  
> Hi, 
>  
>  
>  
> On Monday, May 18, 2015 14:04:37 Hamza Alloush wrote: 
>  
> > steps to produce the issue(line by line): 
>  
> > 
>  
> > 1 - git clone -b master git://git.code.sf.net/p/openrti/OpenRTI && cd  
> OpenRTI 
>  
> > 2 - mkdir build/ install/ && cd build/ 
>  
> > 3 - rm -f CMakeCache.txt && cmake ../ -DCMAKE_BUILD_TYPE="Release"  
> -DCMAKE_INSTALL_PREFIX:PATH=$(dirname `pwd`)/install && make -j4 &&  
> make install 
>  
> > 4 - ldd -d $(dirname `pwd`)/install/lib/x86_64-linux-gnu/libRTI-NG.so 
>  
> > 
>  
> > this entry for rpath(in my case): libOpenRTI.so.1 =>  
> /home/hamza/build/OpenRTI/install/lib/x86_64-linux-gnu/libOpenRTI.so.1  
> (0x00007f109dfd3000) 
>  
> > 
>  
> > now repeat last two steps: 
>  
> > 
>  
> > 5 - rm -f CMakeCache.txt && cmake ../ 
>  
> > -DCMAKE_BUILD_TYPE="Release" -DCMAKE_INSTALL_PREFIX:PATH=$(dirname 
>  
> > `pwd`)/install && make -j4 && make install 
>  
> > 6 - ldd -d $(dirname `pwd`)/install/lib/x86_64-linux-gnu/libRTI-NG.so 
>  
> > 
>  
> > this entry for rpath now becomes: libOpenRTI.so.1 => not found 
>  
> > 
>  
> > i wonder what's the cause of this? 
>  
>  
>  
> I can reproduce this with cmake 3.0.2 on fedora, so me too. 
>  
> I do indeed get two different sets of cmake build files. Especially variables 
>  
> belonging to binutils and the compiler seem to miss in the second version. 
>  
> So it looks to me that cmake reuses more than the CMakeCache.txt. 
>  
> If you also remove CMakeFiles/3.0.2/CMakeC{,XX}Compiler.cmake before  
> calling cmake, 
>  
> you get a correct build again. 
>  
>  
>  
> So, this looks at first like a cmake problem to me? 
>  
>  
>  
> Do you also see similar behavior with other cmake projects beside OpenRTI? 
>  
> I do currently not have one other project in mind that really cares for  
> correct rpaths? 
>  
>  
>  
> To really help in the sort term: 
>  
> I would not suggest to remove the CMakeCache.txt on each new build. 
>  
> All generators I used so far set up correct dependencies. 
>  
> If you really want to remove the cache, may be you should also remove  
> everything else 
>  
> belonging to cmake from the build directories or start with a  
> completely fresh build either. 
>  
>  
>  
> Nevertheless, if you can find out more keep me updated! 
>  
> I agree that this is unexpected and annoying. 
>  
>  
>  
> Greetings 
>  
>  
>  
> Mathias 

Ok, i have tested with all sorts of stuff today, and the only way i got the RPATH to be correct(with partial cache delete), is to replace the assigned value to INSTALL_RPATH for each target executable from "\\\${ORIGIN}" to "${CMAKE_INSTALL_FULL_LIBDIR}".

I'm not sure if this solution is what you expect, but you already have this sort of INSTALL_RPATH assignment in src/qrti/CMakeLists.txt:58, e.g.

  SET_PROPERTY(TARGET qrti PROPERTY INSTALL_RPATH "${CMAKE_INSTALL_FULL_LIBDIR}")
# SET_PROPERTY(TARGET qrti PROPERTY INSTALL_RPATH "\\\${ORIGIN}/../${CMAKE_INSTALL_LIBDIR}")

except for rtinode, almost all target executables use the same INSTALL_RPATH assignment. 

i read this and thought was related, for singular INSTALL_RPATH the CMake website recommends: "If you want the same RPATH settings for executables and shared libraries
 in your source tree, all you have to do is to set the CMake variables 
CMAKE_INSTALL_RPATH, CMAKE_SKIP_BUILD_RPATH, 
CMAKE_BUILD_WITH_INSTALL_RPATH, CMAKE_INSTALL_RPATH_USE_LINK_PATH once, 
e.g. in the top level CMakeLists.txt." http://www.cmake.org/Wiki/CMake_RPATH_handling

is it possible this could be the correct solution? the RPATH's no longer breaking when partial delete cache.

-Hamza