MantisBT - CMake
View Issue Details
0010238CMakeCMakepublic2010-02-04 16:462011-01-17 16:26
irwin 
Brad King 
normalfeaturealways
closedwon't fix 
 
 
0010238: INSTALL_RPATH should be filtered for everything in CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
For the PLplot build system where INSTALL_RPATH is used rather than INSTALL_RPATH_USE_LINK_PATH to determine the RPATH, default locations such as /usr/lib are getting into the long list of RPATH locations from our many external library dependencies. Thus, I must filter those locations by explicit CMake code using CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES. As a convenience to users it would be nice if those default locations were filtered automatically out of the INSTALL_RPATH target property when it is used to determine rpath for installed libraries and executables. This currently happens for rpath determined automatically for the build-tree libraries and executables, and it
would be good to have that happen automatically for the install-tree as well
simply for the sake of consistency.
No tags attached.
related to 0011751closed Brad King ability to filter INSTALL_RPATH (to not include CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES in particular) 
Issue History
2010-02-04 16:46irwinNew Issue
2010-05-08 03:44Alex NeundorfNote Added: 0020655
2010-05-08 12:20irwinNote Added: 0020665
2010-05-08 17:12Alex NeundorfNote Added: 0020667
2010-05-08 19:37irwinNote Added: 0020670
2010-05-09 07:14Modestas VainiusNote Added: 0020685
2010-05-09 14:44irwinNote Added: 0020688
2011-01-17 15:40David ColeAssigned To => Brad King
2011-01-17 15:40David ColeStatusnew => assigned
2011-01-17 16:26Brad KingNote Added: 0024820
2011-01-17 16:26Brad KingStatusassigned => closed
2011-01-17 16:26Brad KingResolutionopen => won't fix
2011-01-24 14:21Brad KingRelationship addedhas duplicate 0011751
2011-01-24 14:24Brad KingRelationship replacedrelated to 0011751

Notes
(0020655)
Alex Neundorf   
2010-05-08 03:44   
Hmm, one could argue that if you tell cmake to put this into the RPATH, then it also should do just that.

Why are you not using INSTALL_RPATH_USE_LINK_PATH ?
I think a useful improvement to INSTALL_RPATH_USE_LINK_PATH would be if it would also add the RPATH of libraries which are used and install with the current project.
Currently it uses all RPATHs from external libraries, and removes the one which were pointing inside the buildtree. So it would be cool if it would, instead of removing those paths, add the install dirs of these in-project targets to the install RPATH.
Would that help in your case ?

Alex
(0020665)
irwin   
2010-05-08 12:20   
"Hmm, one could argue that if you tell cmake to put this into the RPATH, then it also should do just that."

Sure, but then you have the current inconsistency with how rpath is automatically determined in the build tree with the standard library locations filtered out. Furthermore, if you automatically filter out standard library locations from INSTALL_RPATH it does no harm while also providing a useful service (standard locations in the various rpath lists that are combined together by PLplot into the final list used by INSTALL_RPATH make a real mess since if say "/usr/lib" is at the top of the combined list by chance, that means you access the system libraries at run time rather than the ones that you specified in the non-standard locations.)

"Why are you not using INSTALL_RPATH_USE_LINK_PATH ?"

PLplot needs everything given by INSTALL_RPATH_USE_LINK_PATH as well as one additional location (the install location of the PLplot libraries). (N.B. that extra location is optional but useful for those who want to install PLplot into a non-standard location.) We could specify that extra location with INSTALL_RPATH, but I am pretty sure I tried that years ago and it conflicted with INSTALL_RPATH_USE_LINK_PATH. Can you specify both INSTALL_RPATH and INSTALL_RPATH_USE_LINK_PATH now and get a good combined result?
(0020667)
Alex Neundorf   
2010-05-08 17:12   
"Can you specify both INSTALL_RPATH and INSTALL_RPATH_USE_LINK_PATH now and get a good combined result?"

Yes. We do that in KDE.
What do you think about the idea to improve INSTALL_RPATH_USE_LINK_PATH so that it also adds the install location of linked in-project libraries ?

Alex
(0020670)
irwin   
2010-05-08 19:37   
"What do you think about the idea to improve INSTALL_RPATH_USE_LINK_PATH so that it also adds the install location of linked in-project libraries ?"

We have some dynamically loaded plug-ins that are installed in a special directory but which need rpath pointing to our normal installed library location. So that would be counterproductive in that case (unless you specified an additional variable to specify the path you wanted to point to, and it appears from what you said above that INSTALL_RPATH already does that job.

So let's get back to my original request. There is no possible harm in that, and it is still quite a useful idea, I think.
(0020685)
Modestas Vainius   
2010-05-09 07:14   
Well, I don't think that cmake should filter anything what's explicitly specified. Since user explicit specifies INSTALL_RPATH, cmake should not get in between and disregard user wishes by doing some magic. I do believe this will lead to more WTH moments than it's worth.
(0020688)
irwin   
2010-05-09 14:44   
I also hate magic, but the answer is documentation. So I agree with you to
this extent; if filtering of INSTALL_RPATH is implemented, it should be well documented.

The two real questions for the CMake developers are

(1) Is the filtering useful?

(2) Could it ever be harmful?

Suppose through lots of obscure CMake manipulations (usually through find modules of some kind for each external library) you get the following list for INSTALL_RPATH for three separate external libraries:

externlib1path;externlib2path;externlib3path

where externlib2path is a standard location (e.g., "/usr/lib"), and externlib[13]path are non-standard locations. That /usr/lib in the list causes big trouble for the important case where there is an old externlib3 in /usr/lib and you want to use a newer version installed in some non-standard location. (That happens a lot with Qt4 and PLplot where often I want to try out a new version of Qt4 downloaded directly from trolltech.) Instead of using the desired new version you end up with the old system version. So the answer to the first question above is an emphatic yes. Of course, the answer to the second question is an emphatic no since libraries are always searched for at run time in the standard locations as a last resort.

I guess if you can find a counterexample where a standard system location in the middle of a bunch of rpath alternatives is actually useful for a build of a real project, then you have a point, but I frankly cannot imagine such a case.
(0024820)
Brad King   
2011-01-17 16:26   
I agree with 0010238:0020685 that we should not mess with anything that is set explicitly. INSTALL_RPATH is a primitive that we honor blindly. Any filtering should be up to the project based on its own needs.

Generally one can use INSTALL_RPATH_USE_LINK_PATH for third-party dependencies and INSTALL_RPATH for locations installed by the project.