setting EXECUTABLE_OUTPUT_PATH in tier1/ tests ?

[David Faure]

On Thursday 10 May 2012 23:44:31 Stephen Kelly wrote:
> Stephen Kelly wrote:
> > David Faure wrote:
> >> On Thursday 10 May 2012 23:21:55 Stephen Kelly wrote:
> >>> We have RPATH for that. Is that enough?
> >> 
> >> Doesn't seem to work currently.
> >> 
> >> Apply attached patch in kcoreaddons, make, then try to run
> >> ./krandomsequencetest:
> >> 
> >> ./krandomsequencetest: symbol lookup error: ./krandomsequencetest:
> >> undefined symbol: _ZN7KBackup10helloSteveEv
> > 
> > helloDavid();
> > 
> > :)
> > :
> >> Hmm, let's investigate:
> >> 
> >> ldd ./krandomsequencetest | grep kcoreadd
> >> 
> >>         libkcoreaddons.so.5 =>
> >>         /d/kde/inst/kde_frameworks/lib64/libkcoreaddons.so.5
> >>         (0x00007ff56b385000)
> >> 
> >> objdump -p krandomsequencetest | grep PATH
> >> 
> >>   RPATH
> >>   /d/qt/4/qt-for-trunk/lib:/d/kde/build/5/kdelibs-
> > 
> > frameworks/tier1/kcoreaddons/src:/d/kde/build/5/kdelibs-
> > frameworks/libinqt5/src:/d/kde/build/5/kdelibs-
> > frameworks/libkdeqt5staging/src
> > 
> >>   RUNPATH
> >>   /d/qt/4/qt-for-trunk/lib:/d/kde/build/5/kdelibs-
> > 
> > frameworks/tier1/kcoreaddons/src:/d/kde/build/5/kdelibs-
> > frameworks/libinqt5/src:/d/kde/build/5/kdelibs-
> > frameworks/libkdeqt5staging/src
> > 
> >> Hmm, so this comes from $LD_LIBRARY_PATH pointing to $KDEDIR/lib64.
> >> Emptying it works: LD_LIBRARY_PATH= ldd ./krandomsequencetest | grep
> >> kcoreadd
> >> 
> >>         libkcoreaddons.so.5 =>
> >>         /d/kde/build/5/kdelibs-
> > 
> > frameworks/tier1/kcoreaddons/src/libkcoreaddons.so.5
> > 
> >>         (0x00007f506c524000)
> >> 
> >> But wasn't RPATH supposed to take precedence over $LD_LIBRARY_PATH?
> 
> 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.

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

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?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5