[CMake] another RPATH problem

Brad King brad.king at kitware.com
Mon Jun 12 15:42:05 EDT 2006


Alexander Neundorf wrote:
> Hi,
> 
> although cmake now supports RPATH very flexible, we still have a problem.
> The install RPATH has to be constructed manually. In KDE we set it to the Qt libdir, the KDE libdir and the install libdir.
> Now the problem is, what to do if the app links to a library which has been found (e.g. /usr/lib/dbus/lib/libdbus-1.so ) but which isn't in the LD_LIBRARY_PATH ?
> Requiring every developer to adjust the INSTALL_RPATH manually for every lib he links to doesn't seem like a viable solution.
> Another option is just to require that (DY)LD_LIBRARY_PATH is set up correctly.
> 
> But I see a third option which sounds quite compelling to me.
> When linking and when relinking during install, cmake adds all required link dirs using -L ... to the command line.
> Shouldn't it be possible to use the same set of link dirs also for the RPATH ?
> This would solve all our problems I think.

It will be hard to separate build-tree linking dirs from install-tree 
linking dirs.  Consider a pair of projects A and B.  I build A, and then 
build B using the build tree of A to link its libraries.  Then I install 
both.  Now B's rpath will point at the build tree of A instead of its 
install location.

Every project will have its own policy of RPATH/no-rpath/etc.  I think 
the best solution is to have the Find*.cmake scripts provide a 
FOO_RUNTIME_LIBRARY_DIR variable along with FOO_LIBRARY and 
FOO_INCLUDE_DIR.  This directory could then be used for the RPATH of 
something that links to FOO.  Also on Windows it would provide the 
location of foo.dll which may be different from that of the foo.lib 
being linked.

-Brad


More information about the CMake mailing list