setting EXECUTABLE_OUTPUT_PATH in tier1/ tests ? (RPATH related)

[Alexander Neundorf]

On Friday 11 May 2012, Alexander Neundorf wrote:
> On Friday 11 May 2012, David Faure wrote:
> > On Thursday 10 May 2012 23:44:31 Stephen Kelly wrote:
> ...
> 
> > > http://labs.qt.nokia.com/2011/10/28/rpath-and-runpath/
> > 
> > Thanks. So the problem is that the mere presence of RUNPATH, disables the
> > (deprecated) RPATH, and therefore $LD_LIBRARY_PATH is used, i.e. the
> > installed libs are picked up.
> 
> Yes.
> http://www.cmake.org/Wiki/CMake_RPATH_handling
> 
> > For a developer working on a given framework that's not a huge deal, but
> > for simply running "make ; make test" in all frameworks, this is an
> > issue. This is exactly what the wrapper scripts were solving in
> > kdelibs-4...
> 
> They were mainly intended for the CMAKE_SKIP_RPATH=TRUE case.
> I can't remember that I got any feedback on them, which makes me think that
> the wrapper scripts were mostly unknown.
> Creating those in kde4_add_executable() was no problem, but since one of
> the goals is to use plain cmake commands, i.e. add_executable(), this
> cannot be done automatically anymore.
> 
> > Surely we must not be the only cmake users who make shared libs and
> > unittests for these libs -- and the tests are supposed to pick up the
> > uninstalled libs. Can cmake get the "wrapper scripts" feature? Or is
> > there a RPATH setting that would fit better for this?
> 
> We enable RUNPATH explicitely, it's not cmake's fault.
> If we would not add --enable-new-dtags, everything would just work.
> 
> IMO RPATH and RUNPATH are just two different behaviours, which one is
> considered "better" is IMO subjective.
> (IOW I haven't understood why RUNPATH is claimed to be The Right Thing).

Here is the discussion from December 2007:
http://lists.kde.org/?t=119779766900001&r=1&w=2
and here's your commit:
http://quickgit.kde.org/index.php?p=kdelibs.git&a=commit&h=ad58627f978acdb9a0596090d06a1cdefc3ec137

Things have changed a bit since then.
If RPATH is enabled (i.e. CMAKE_SKIP_RPATH has not been set to TRUE), we now 
check whether LIB_INSTALL_DIR is a system library directory, and only add it 
to RPATH if it is not.
Additionally, cmake can now change the RPATH inside an ELF file, so the 
argument that using different build- and install-RPATHs increases 
build/install time is not valid anymore.

So, are there still reasons for using RUNPATH over RPATH ?
Using RPATH instead of RUNPATH would make our unit tests run reliably in all 
cases.

Here is the debian page on it:
http://wiki.debian.org/RpathIssue
Doesn't Debian simply disable RPATH completely anyway ?

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120512/4cf145b5/attachment.html>