Currently, Qt and KDE libraries are built with an RPATH (usually RPATH=/usr/lib/qt4). This results in conflicts with binaries that come with their own libraries, like Qt Creator. The Creator guys are nice enough to provide a generic installer that works for all Linux distros and don't just drop an RPM or DEB in your face and that's that. So when you install Creator 2.3.0 RC (which you can't build on Gentoo yet since Qt 4.7.4 was not released yet), it won't load because the system's libs/plugins have an RPATH set and it loads the wrong libs and the application aborts. This seems to only happen in Gentoo (other distros don't use an RPATH). I filed an upstream bug about it, and it was pointed out by an upstream developer that: "the problem affects only gentoo users, as other distros don't seem to compile plugins with a RUNPATH (as doing so is rather braindead)." The bug: https://bugreports.qt.nokia.com/browse/QTCREATORBUG-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161840#comment-161840 So why do we have the affected libs built with an RPATH? KDE is not slotted anymore (it was in the past.) Neither is Qt. So getting rid of the RPATH might be a good idea. Reproducible: Always
As for KDE, I agree with Ossi (KDE developer) - forcing RPATH is more or less braindead. But it's what *KDE* does in FindKDE4Internal.cmake by default. We don't explicitly set RPATH anymore for KDE since we dropped kdeprefix, yet we do not explicitly disable setting RPATH (a mistake maybe to let upstream decide). When linking KDE libraries, CMake does something around figuring out RPATH of library dependencies and appending them to resulting RPATH. Since Qt4 libraries have RPATH set to PREFIX/qt4, all KDE apps using CMake will have RPATH entries inherited from Qt4. So in general dropping RPATH from Qt4 should fix the issue for packages being rebuilt afterwards.
@qt: what do you think?
Does dropping rpath imply moving qt libraries from /usr/lib/qt4 to /usr/lib too?
(In reply to comment #3) > Does dropping rpath imply moving qt libraries from /usr/lib/qt4 to /usr/lib > too? No. /usr/lib/qt4, just like /usr/lib, is in /etc/ld.so.conf.
(In reply to comment #4) > (In reply to comment #3) > > Does dropping rpath imply moving qt libraries from /usr/lib/qt4 to /usr/lib > > too? > > No. /usr/lib/qt4, just like /usr/lib, is in /etc/ld.so.conf. Well... I thought using a proper rpath was considered better than adding stuff to LDPATH. That's why I filed bug #347868 some time ago, inspired by http://blog.flameeyes.eu/2008/12/30/avoid-ldpath-pollution
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Does dropping rpath imply moving qt libraries from /usr/lib/qt4 to /usr/lib > > > too? > > > > No. /usr/lib/qt4, just like /usr/lib, is in /etc/ld.so.conf. > > Well... I thought using a proper rpath was considered better than adding stuff > to LDPATH. That's why I filed bug #347868 some time ago, inspired by > http://blog.flameeyes.eu/2008/12/30/avoid-ldpath-pollution Diego wrote: "make sure that there is a proper runpath in the executables" In the executables, not the libraries :-)
So there are two obvious paths of action here: 1) we fix kde not to copy the RPATH or 2) RPATH gets dropped from qt (or 3) do nothing).
@qt: it's your decision if you are interested in dropping RPATH etc from the qt libraries, give me qt ebuilds for testing and I will rebuild my world with it... this should propagate to kde then.
Fixed for Qt 4.8 and later. Thanks Andreas!
Thanks everyone for working on it. I'm not sure if it's safe to check this myself (once Qt 4.8 is in the tree), since I'm on KDE 4.7.4. Is it OK to use with that KDE version?
(In reply to comment #10) > Thanks everyone for working on it. I'm not sure if it's safe to check this > myself (once Qt 4.8 is in the tree), since I'm on KDE 4.7.4. Is it OK to use > with that KDE version? I'm testing with 4.7.4 :) It's maybe not fully fixed yet, but whatever RPATH is left is a KDE (or CMake) bug, not Qt's fault. Testing... installing 249 of 813... :o)8
