kdesupport rpath issues

[Alexander Neundorf]

On Friday 12 February 2010, Rex Dieter wrote:
> Maciej Mrozowski wrote:
> > On Friday 12 of February 2010 16:36:31 Rex Dieter wrote:
> >> I'm on Fedora 12, using cmake-2.8.0
> >>
> >> For me, building many kdesupport items, I end up with binaries and
> >> libraries that have rpaths containing /usr/lib64 (or /usr/lib on 32
> >> bit). As I understand it, normal system library paths shouldn't be
> >> rpath'd.
> >>
> >> I've seen this so far trying to build:  akonadi, attica, strigi, soprano
> >>
> >> Is this expected?
> >>
> >> (At first I thought it to be a generalized cmake problem, but I've also
> >> tested several other non-kdesupport cmake-based projects without
> >> problems, including libmusicbrainz, openjpeg, qcomicbook)
> >
> > It's expected according to soprano or strigi CMakeLists.txt:
>
> ...
>
> > It's been put there purposely it seems as a safe default for developers
> > and alike.
> > I think you can still disable it if you're sure you install those libs in
> > standard location in your distribution (say /usr/lib${LIB_SUFFIX)) by
> > passing -DCMAKE_SKIP_RPATH=ON to cmake.
>
> Eww.  OK, we ran into this with FindKDE4Internal.cmake too, and came up
> with this hackish patch, I'd appreciate if it got some feedback/love from
> someone with more cmake-fu than I, and we can hopefully get this
> upstreamed.
>
> The intention here is to simply not rpath anything in
> ${CMAKE_SYSTEM_LIBRARY_PATH}
> but maybe I'm oversimplifying.

Why do you do this ?

-      set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
+      set(CMAKE_INSTALL_RPATH_USE_LINK_PATH FALSE)

Then you have to manually collect all RPATHs you need (e.g. if some libs were 
in /opt/ or /home/foo/lib/ or ... ) , the only RPATH will be the one from 
CMAKE_INSTALL_RPATH.

Alex