setting EXECUTABLE_OUTPUT_PATH in tier1/ tests ? (RPATH related)

[Alexander Neundorf]

On Sunday 13 May 2012, David Faure wrote:
> On Saturday 12 May 2012 21:50:51 Alexander Neundorf wrote:
> > Using RPATH instead of RUNPATH would make our unit tests run reliably in
> > all  cases.
> 
> Yep, I would like that :)
> 
> The only case I can think of, where RUNPATH is better than RPATH, is when
> you want to force an existing KDE installation to use a different library
> (Qt, or any other lib) than the one it was compiled with. You set
> $LD_LIBRARY_PATH to that effect, and... no change, it keeps using the
> rpath that got hardcoded into the executables. This is why I thought
> RUNPATH was better (gives more control to the user), but now I see that we
> don't always want that (unittest case).
> 
> On the other hand, if *everything* has a proper RUNPATH, then maybe the
> fault is on my side, I just shouldn't set LD_LIBRARY_PATH at all?
> 
> Hmm, doesn't work currently:
> objdump -p /d/kde/inst/kde_frameworks-qt5/lib64/kde5/libexec/kioslave
>   RPATH                lib64:/d/qt/5/qtbase-master/lib
>   RUNPATH            lib64:/d/qt/5/qtbase-master/lib
> This looks wrong, the first entry should be
>   /d/kde/inst/kde_frameworks-qt5/lib64

Oh, right, this is wrong.
This is because the install dirs (LIB_INSTALL_DIR etc.) are now relative by 
default, i.e. simply "lib64" instead of "${CMAKE_INSTALL_PREFIX}/lib64".

I'll fix that.
... that's why I did not want to touch that install dir stuff during KDE4...

Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120513/f51918ae/attachment-0001.html>