[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: libkparts.so.4: cannot open shared object file
From: Alexander Neundorf <neundorf () kde ! org>
Date: 2007-12-18 16:16:46
Message-ID: 200712181716.46441.neundorf () kde ! org
[Download RAW message or body]
On Tuesday 18 December 2007, David Faure wrote:
...
> Yep. But then I really don't understand this comment and code from
> KDE4Macros.cmake... Alex?
>
> # If RPATH is not explicitly disabled, libraries and plugins are built
> without RPATH, in # the hope that the RPATH which is compiled into the
> executable is good enough. macro (KDE4_HANDLE_RPATH_FOR_LIBRARY
> _target_NAME)
> if (NOT CMAKE_SKIP_RPATH AND NOT KDE4_USE_ALWAYS_FULL_RPATH)
> set_target_properties(${_target_NAME} PROPERTIES
> INSTALL_RPATH_USE_LINK_PATH FALSE SKIP_BUILD_RPATH TRUE
> BUILD_WITH_INSTALL_RPATH TRUE INSTALL _RPATH "")
> endif (NOT CMAKE_SKIP_RPATH AND NOT KDE4_USE_ALWAYS_FULL_RPATH)
> endmacro (KDE4_HANDLE_RPATH_FOR_LIBRARY)
>
> So this macro does nothing when KDE4_USE_ALWAYS_FULL_RPATH is ON, which is
> the default now, right? So how do shared libs get an RPATH like Thiago
> noticed?
The default RPATH behaviour is set in FindKDE4Internal.cmake, and this macro
sets the install RPATH for libraries to empty, except when
KDE4_USE_ALWAYS_FULL_RPATH is set, then it is also the full install RPATH for
libs.
Alex
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic