Hi,
I think there is a bug in the way CMake handles rpath for installed targets.
My GCC installation contains the following definition in the specs file:
*link_libgcc:
%D -rpath <<some specific rpath in which libstdc++.so can be found>>This configuration leads to the following bug in CMake: Whenever a target (which depends on a library in the project) is created, the rpath is completely removed from the installed targets (including the linker's predefined rpath). This is not the case when there are no dependencies on other libraries in the project. Of course this can be fixed by changing CMake rpath-related variables but I think that this suggests that the default rpath handling should be fixed. (Note that the same behavior happens when "-Wl,-rpath" is used in CMAKE_EXE_LINKER_FLAGS) Specifically, I think that the command "FILE(RPATH_REMOVE ...)" is not subtle enough, as it removes the compiler's predefined rpath together with the rpath added by CMake. I suggest replacing it with the command "FILE(RPATH_CHANGE ...)" (even when NEW_RPATH is empty) and allowing this command to decide (based on the actual rpath defined in the file) whether the rpath entry should be removed. Attached is the suggested patch. Please let me know what you think. Thanks, Lior
0001-Use-RPATH_CHANGE-instead-of-RPATH_REMOVE.patch
Description: Binary data
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
