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