[CMake] another RPATH problem

[Alexander Neundorf]

Hi,

Von: Brad King <brad.king at kitware.com>

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

Two independent projects as in two independent source trees and then one of them is built against the uninstalled other ?
E.g. like building kdebase against an uninstalled kdelibs ?
The cmake FindFoo.cmake modules won't find the uninstalled libs, so manual adjustment is required. 
If in this case something strange happens if the (not yet existant) option to use the "external" RPATH also for installing is enabled, then it's acceptable I'd say.
 
> 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.  

I think extracting the directory part from the full name of the library would do the job too.
Still this would mean that every developer has to deal with this if he adds another library.
And average developers (like me until maybe three months ago) often don't really know how to deal best with RPATH stuff.

> Also on Windows it would provide the 
> location of foo.dll which may be different from that of the foo.lib 
> being linked.

Attached you can find a patch against current cvs which adds an option with the nice name CMAKE_USE_EXTERNAL_RPATH_FOR_INSTALL, which if enabled has the effect that lib dirs which are outside the build- and source tree are added to the install RPATH.

Please take it into consideration, IMO it might be useful.

Bye
Alex

-- 


Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmLocalGenerator.cxx.external_rpath.patch
Type: text/x-diff
Size: 1592 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/cmake/attachments/20060614/945aabaf/cmLocalGenerator.cxx.external_rpath.bin