New dependency for kdelibs and kdebase: dbusmenu-qt

Modestas Vainius modestas at
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
> 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
> 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:

line 998.

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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the kde-core-devel mailing list