[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