MantisBT - CMake
View Issue Details
0011751CMakeCMakepublic2011-01-24 13:542016-06-10 14:31
Rex Dieter 
Brad King 
normalfeaturealways
closedmoved 
CMake 2.8.3 
 
0011751: ability to filter INSTALL_RPATH (to not include CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES in particular)
Similar to bug 0010238 , what I want is that CMAKE_INSTALL_RPATH_USE_LINK_PATH not include directories listed in CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES

The particular use-case, is for packaging cmake-based projects for a linux distribution (fedora), where including rpath's for items in CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES is against policy and considered harmful.

As it is, there seems to be no easy way to sanely filter cmake rpaths short of using overly-big hammers like
* patching cmake-project code to filter on a case-by-case basis
* use CMAKE_NO_RPATH
See also thread,
http://mail.kde.org/pipermail/kde-buildsystem/2011-January/007560.html [^]
No tags attached.
related to 0010238closed Brad King INSTALL_RPATH should be filtered for everything in CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES 
Issue History
2011-01-24 13:54Rex DieterNew Issue
2011-01-24 14:21Brad KingRelationship addedduplicate of 0010238
2011-01-24 14:24Brad KingNote Added: 0025027
2011-01-24 14:24Brad KingRelationship replacedrelated to 0010238
2011-01-24 14:25Brad KingNote Edited: 0025027bug_revision_view_page.php?bugnote_id=25027#r155
2011-01-24 14:25Brad KingAssigned To => Brad King
2011-01-24 14:25Brad KingStatusnew => assigned
2011-01-24 14:35Rex DieterNote Added: 0025028
2011-01-24 14:41Brad KingNote Added: 0025029
2011-01-24 14:42Brad KingNote Added: 0025030
2011-01-24 14:47Brad KingNote Added: 0025031
2011-01-24 14:48Rex DieterNote Added: 0025032
2011-01-24 15:36Alex NeundorfNote Added: 0025038
2011-01-24 15:50Modestas VainiusNote Added: 0025041
2011-01-24 16:12Alex NeundorfNote Added: 0025046
2011-01-24 16:28Modestas VainiusNote Added: 0025047
2011-01-24 16:32Alex NeundorfNote Added: 0025048
2011-01-24 16:34Modestas VainiusNote Added: 0025049
2011-01-24 16:34Brad KingNote Added: 0025050
2011-01-24 16:39Brad KingNote Added: 0025051
2011-01-24 16:42Brad KingNote Added: 0025052
2011-01-24 16:43Brad KingNote Added: 0025053
2011-01-24 16:45Brad KingNote Edited: 0025041bug_revision_view_page.php?bugnote_id=25041#r157
2011-01-24 16:47Modestas VainiusNote Added: 0025054
2011-01-24 16:50Brad KingNote Added: 0025055
2011-01-24 16:54Modestas VainiusNote Added: 0025056
2011-01-24 16:54Modestas VainiusNote Edited: 0025056bug_revision_view_page.php?bugnote_id=25056#r159
2011-01-24 16:58Modestas VainiusNote Added: 0025057
2011-01-24 16:58Modestas VainiusNote Edited: 0025057bug_revision_view_page.php?bugnote_id=25057#r161
2011-01-24 17:10Alex NeundorfNote Added: 0025061
2011-01-24 17:15Modestas VainiusNote Added: 0025062
2011-01-25 08:37Brad KingNote Added: 0025066
2011-01-25 08:37Brad KingNote Edited: 0025061bug_revision_view_page.php?bugnote_id=25061#r163
2011-01-25 08:47Brad KingNote Added: 0025067
2011-01-25 09:27Rex DieterNote Added: 0025070
2011-01-25 09:32Brad KingNote Added: 0025071
2011-01-25 13:32Alex NeundorfNote Added: 0025074
2011-01-25 15:18Modestas VainiusNote Added: 0025075
2012-08-13 10:36Brad KingStatusassigned => backlog
2012-08-13 10:36Brad KingNote Added: 0030480
2016-06-10 14:28Kitware RobotNote Added: 0041783
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0025027)
Brad King   
2011-01-24 14:24   
(edited on: 2011-01-24 14:25)
As discussed in 0010238, the INSTALL_RPATH property is a primitive. CMake doesn't set it to anything and honors it exactly as the project sets it. If you don't want a certain path in it, don't add it.

I can see a case for CMAKE_INSTALL_RPATH_USE_LINK_PATH though.

(0025028)
Rex Dieter   
2011-01-24 14:35   
For a concrete example, I was hoping to avoid having to add this same loop all over the place,

list(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${LIB_INSTALL_DIR}" _isSystemLibDir)
if("${_isSystemLibDir}" STREQUAL "-1")
  set(CMAKE_INSTALL_RPATH "${LIB_INSTALL_DIR}")
endif("${_isSystemLibDir}" STREQUAL "-1")
(0025029)
Brad King   
2011-01-24 14:41   
macro(append_install_rpath dir)
  list(FIND CMAKE_INSTALL_RPATH "${dir}" _exists)
  list(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${dir}" _isSystem)
  if("${_exists}" LESS 0 AND "${_isSystem}" LESS 0)
    list(APPEND CMAKE_INSTALL_RPATH "${path}")
  endif()
endmacro()
(0025030)
Brad King   
2011-01-24 14:42   
Another basic problem here is that the value of CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES is a *guess* and is not computed from the actual system.
(0025031)
Brad King   
2011-01-24 14:47   
OTOH, cmComputeLinkInformation::LoadImplicitLinkInfo does know about the real implicit directories computed from the system:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0de8be8b [^]

This is an argument for doing the filtering in CMake. However, both INSTALL_RPATH_USE_LINK_PATH and INSTALL_RPATH are primitives that should be respected.

What we need is a *new* primitive meant specifically for filtering.
(0025032)
Rex Dieter   
2011-01-24 14:48   
thanks for the macro! We could try to add that to set available to kde projects at least.
(0025038)
Alex Neundorf   
2011-01-24 15:36   
Since INSTALL_RPATH_USE_LINK_PATH is computed automatically by cmake (as opposed to INSTALL_RPATH which is set explicitely by the user), modifying the behaviour so that the implicit directories are not included can be seen as a bug fix. Probably most distro people see it this way.

Alex
(0025041)
Modestas Vainius   
2011-01-24 15:50   
(edited on: 2011-01-24 16:45)
KDE's problem is set(CMAKE_INSTALL_RPATH "${LIB_INSTALL_DIR}") where LIB_INSTALL_DIR is /usr/lib. /usr/lib is never added (or not that I'm aware of) to RPATH due to INSTALL_RPATH_USE_LINK_PATH being true, i.e. it's not KDE's problem. So INSTALL_RPATH_USE_LINK_PATH filtering might be a good idea but the hack in comment 0011751:0025028 will still be needed.

Feel free to prove me wrong.

(0025046)
Alex Neundorf   
2011-01-24 16:12   
While I don't completely understand your first sentence you are right that the macro only affect INSTALL_RPATH but not INSTALL_RPATH_USE_LINK_PATH.

I think this bug report here should focus on INSTALL_RPATH_USE_LINK_PATH.

Am I right that this issue is getting more important now since slowly the number of non-KDE cmake-built projects is increasing, and they all have to take care of RPATH settings themselves ?

Alex
(0025047)
Modestas Vainius   
2011-01-24 16:28   
Sorry for stupid question but how typically the path gets added to the "linker search path"? I'm just trying to understand how INSTALL_RPATH_USE_LINK_PATH works. Is this the topic of CMP0003?
(0025048)
Alex Neundorf   
2011-01-24 16:32   
E.g. if a target foo is linked in CMakeLists.txt against /some/dir/lib/libblub.so, /some/dir/lib/ is added to the list of directories for this target.
Is this what you mean ?

Alex
(0025049)
Modestas Vainius   
2011-01-24 16:34   
Even if CMP0003 is NEW?
(0025050)
Brad King   
2011-01-24 16:34   
Modestas, your question in 0011751:0025047 is definitely *not* stupid! Basically it is every directory added by the link_directories command plus directories containing shared libraries that get linked via full path.
(0025051)
Brad King   
2011-01-24 16:39   
CMP0003 is related but does not actually affect this behavior. It affects whether the directories containing libraries linked via full path are added to the link line with -L (whether or not they are shared).
(0025052)
Brad King   
2011-01-24 16:42   
Anyway, it appears to me that INSTALL_RPATH_USE_LINK_PATH has always been filtered to avoid implicit directories. I tested back to CMake 2.6.4. I can pick any directory added by the option, add it to CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES, and it disappears.

Can anyone reproduce otherwise?
(0025053)
Brad King   
2011-01-24 16:43   
Furthermore, CMake 2.8.0 and above also filter by the detected implicit linker search path (such as /usr/lib/gcc/x86_64-linux-gnu/4.4.5).
(0025054)
Modestas Vainius   
2011-01-24 16:47   
Ok, so:

$ cmake --version
cmake version 2.8.3

$ cat CMakeLists.txt
project(test)
cmake_minimum_required(VERSION 2.6)
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH true)
add_library(test SHARED test.c)
target_link_libraries(test /usr/lib/libQtCore.so.4)

$ rm CMakeCache.txt libtest.* && cmake . && make VERBOSE=1
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/modax/test
/usr/bin/cmake -H/home/modax/test -B/home/modax/test --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/modax/test/CMakeFiles /home/modax/test/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/modax/test'
make -f CMakeFiles/test.dir/build.make CMakeFiles/test.dir/depend
make[2]: Entering directory `/home/modax/test'
cd /home/modax/test && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/modax/test /home/modax/test /home/modax/test /home/modax/test /home/modax/test/CMakeFiles/test.dir/DependInfo.cmake --color=
Dependee "/home/modax/test/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/home/modax/test/CMakeFiles/test.dir/depend.internal".
Scanning dependencies of target test
make[2]: Leaving directory `/home/modax/test'
make -f CMakeFiles/test.dir/build.make CMakeFiles/test.dir/build
make[2]: Entering directory `/home/modax/test'
Linking C shared library libtest.so
/usr/bin/cmake -E cmake_link_script CMakeFiles/test.dir/link.txt --verbose=1
/usr/bin/gcc -fPIC -shared -Wl,-soname,libtest.so -o libtest.so CMakeFiles/test.dir/test.c.o /usr/lib/libQtCore.so.4
make[2]: Leaving directory `/home/modax/test'
/usr/bin/cmake -E cmake_progress_report /home/modax/test/CMakeFiles 1
[100%] Built target test
make[1]: Leaving directory `/home/modax/test'
/usr/bin/cmake -E cmake_progress_start /home/modax/test/CMakeFiles 0

$ objdump -p libtest.so | grep RPATH
$

So why /usr/lib was not added to RPATH even if I specified libQtCore.so.4 with full path? Maybe I miss something? Or filtering is already happening?
(0025055)
Brad King   
2011-01-24 16:50   
0011751:0025054:

That's the version of the library in the *build* tree. After "make install" you will see something different.
(0025056)
Modestas Vainius   
2011-01-24 16:54   
Ok, so that's what I wanted to say in comment 0011751:0025041. INSTALL_RPATH_USE_LINK_PATH=true is not a problem. The way KDE (used to) set INSTALL_RPATH was a problem.

Now that long 4-line hack which Rex posted (and which KDE uses) is really non-obvious, inconvenient and looks ugly. IMHO, we should find a solution which is more user friendly.

Yet as I already stated in bug 0010238, filtering out what's explicitly specified is not a good idea.

(0025057)
Modestas Vainius   
2011-01-24 16:58   
Nop.

I added the following to the bottom of CMakeLists.txt

install(TARGETS test LIBRARY DESTINATION lib)

$ sudo make install
[100%] Built target test
Install the project...
-- Install configuration: ""
-- Up-to-date: /usr/local/lib/libtest.so
$ objdump -p /usr/local/lib/libtest.so | grep RPATH
$

(0025061)
Alex Neundorf   
2011-01-24 17:10   
(edited on: 2011-01-25 08:37)
Re 0011751:0025056: the purpose of setting INSTALL_RPATH to the LIB_INSTALL_DIR is for the case that in your project a library is built and installed, and another target in your project links to that library.
In the build tree it will have the RPATH to the build tree location, after installing, that RPATH will have been removed, and is not be added automatically via INSTALL_RPATH_USE_LINK_PATH.
So the non-obvious code states exactly that, add the lib install dir to the RPATH if it is not a system library dir.

Yes, this is easy to get wrong. Or in other words, I think more or less no average developer would get this right on his own.

I still think it would be nice if INSTALL_RPATH_USE_LINK_PATH would also take care of the libraries installed and linked against by the project itself (0010238:0020655)

Alex

(0025062)
Modestas Vainius   
2011-01-24 17:15   
Alex, I agree. This bug should be how to avoid that non-obvious INSTALL_RPATH code and have the same effect in the end.
(0025066)
Brad King   
2011-01-25 08:37   
0011751:0025057: That is expected. I had misread your previous question thinking that you were reporting that /usr/lib *was* in the RPATH. Both the in-build-tree RPATH and INSTALL_RPATH_USE_LINK_PATH are filtered against implicit directories already.

BTW, in Mantis you can use a tilda (~) followed by the comment number to reference it with a link.
(0025067)
Brad King   
2011-01-25 08:47   
0011751:0025062: That makes sense. I don't think the behavior should be done automatically by INSTALL_RPATH_USE_LINK_PATH though because it would be a change in long-established behavior and prevents install trees from being relocatable. Also the install destination of the libraries has nothing to do with the "link path". Whatever solves this will have to be something new and explicitly activated IMO.

The macro in 0011751:0025029 helps.
(0025070)
Rex Dieter   
2011-01-25 09:27   
Re: bug 0011751#c25052

If I understand your comment there, that CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES are already filtered, I can say that's not true for me, else I wouldn't have bothered filing this bug. :) If I misunderstood (happens a lot!), then nevermind.


ps/offtopic: I really dislike this bug tracker's behavior of sending a copy of the *entire* bug dialog on every added comment. :(
(0025071)
Brad King   
2011-01-25 09:32   
0011751:0025070: The directories are already filtered out of what CMake adds automatically when INSTALL_RPATH_USE_LINK_PATH is enabled. There is no filtering of INSTALL_RPATH. Previous discussion in this issue has already concluded that the latter should not be filtered since it is a primitive explicitly set by user code. The open issue is 0011751:0025062.
(0025074)
Alex Neundorf   
2011-01-25 13:32   
0011751:0025066: when I add the lib install dir via RPATH manually, the package is also not relocatable. So this would/could be a problem if some project depends on finding 3rd party libs via RPATH, but uses e.g. wrapper scripts with LD_LIBRARY_PATH for finding its own libs. Don't know if some projects do that.
I think relocatable is only possible (independent from cmake) if e.g. with ELF $ORIGIN is used. This is probably ok for having shared libs find other shared libs installed to the same directory, but it becomes harder for executables, which might be installed to some other location, so figuring out the relative path to the libs may be harder (in easy cases it may be also obvious, like $ORIGIN/../lib ).

Alex
(0025075)
Modestas Vainius   
2011-01-25 15:18   
Re 0011751:0025070:

It seems that you confused CMAKE_INSTALL_RPATH_USE_LINK_PATH with CMAKE_INSTALL_RPATH. I.e. the summary and description of the bug contradict each other. The summary mentions INSTALL_RPATH while the description refers to CMAKE_INSTALL_RPATH_USE_LINK_PATH.

What's know is that RPATHs added by INSTALL_RPATH_USE_LINK_PATH are already filtered (and they have never been a problem for KDE) while RPATHs added by INSTALL_RPATH are not (because they are explicit).

If INSTALL_RPATH_USE_LINK_PATH functionality was extended (or similar option added) as Alex suggests in 0011751:0025061 there would no longer be a need to manually set INSTALL_RPATH at all and the problem would go away.
(0030480)
Brad King   
2012-08-13 10:36   
Sending issues I'm not actively working on to the backlog to await someone with time for them.

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it:

 http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer or contributor who has the bandwidth to take it on.
(0041783)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.