New dependency for kdelibs and kdebase: dbusmenu-qt
modestas at vainius.eu
Fri May 7 22:35:11 BST 2010
On šeštadienis 08 Gegužė 2010 00:11:07 Alexander Neundorf wrote:
> Ok, now I actually tested it.
> Please try the attached example yourself.
> It links an executable with one library in /lib/, one in /usr/lib/, one
> in /usr/local/lib/, and one in /opt/kdelibs/lib/, with
> INSTALL_RPATH_USE_LINK_PATH enabled.
> Resulting RPATHS in the installed executable:
> cmake 2.4.5: /opt/kdelibs/lib:/usr/local/lib:/lib
> cmake 2.6.2: /opt/kdelibs/lib:/usr/local/lib
> cmake 2.8.1: /opt/kdelibs/lib:/usr/local/lib
> cmake 2.8.1 with /usr/local/lib added to
> CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES in
> Modules/Platform/UnixPath.cmake: /opt/kdelibs/lib
> So the directories listed in CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES are
> not added to the RPATH by cmake.
Well ok, so cmake is smart enough for INSTALL_RPATH_USE_LINK_PATH. Apparently,
INSTALL_RPATH_USE_LINK_PATH is ok to enabled by default.
But the problem is that KDE sets CMAKE_INSTALL_RPATH / INSTALL_RPATH manually
in numerous places as well. For example, the following propagates this bad
practise to all KDE applications:
So those CMAKE_INSTALL_RPATH are what I had to patch out mostly. Basically,
grepping for CMAKE_INSTALL_RPATH and INSTALL_RPATH target property would
reveal all evil cases. However, I have a feeling they are redundant even in
your setup when INSTALL_RPATH_USE_LINK_PATH is in effect?
Modestas Vainius <modestas at vainius.eu>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel