Security, please give a suggestion here. Current Qt 4.3.0 builds will create this situation: TYPE RPATH FILE ET_DYN /usr/lib64/qt4 /usr/lib/qt4/libQtScript.so.4.3.0 ET_DYN /usr/lib64/qt4 /usr/lib/qt4/libQtTest.so.4.3.0 ET_DYN /usr/lib64/qt4 /usr/lib/qt4/libQtDesigner.so.4.3.0 ET_DYN /usr/lib64/qt4 /usr/lib/qt4/plugins/inputmethods/libqimsw-multi.so ET_DYN /usr/lib64/qt4 /usr/lib/qt4/plugins/codecs/libqtwcodecs.so ET_DYN /usr/lib64/qt4 /usr/lib/qt4/plugins/codecs/libqkrcodecs.so ET_DYN /usr/lib64/qt4 /usr/lib/qt4/plugins/codecs/libqjpcodecs.so ET_DYN /usr/lib64/qt4 /usr/lib/qt4/plugins/codecs/libqcncodecs.so ET_DYN /usr/lib64/qt4 /usr/lib/qt4/plugins/iconengines/libqsvg.so ET_DYN /usr/lib64/qt4 /usr/lib/qt4/plugins/imageformats/libqgif.so ET_DYN /usr/lib64/qt4 /usr/lib/qt4/plugins/imageformats/libqsvg.so ET_DYN /usr/lib64/qt4 /usr/lib/qt4/plugins/imageformats/libqjpeg.so ET_DYN /usr/lib64/qt4 /usr/lib/qt4/plugins/imageformats/libqmng.so ET_DYN /usr/lib64/qt4 /usr/lib/qt4/plugins/imageformats/libqtiff.so ET_DYN /usr/lib64/qt4 /usr/lib/qt4/plugins/designer/libarthurplugin.so ET_DYN /usr/lib64/qt4 /usr/lib/qt4/libQtXml.so.4.3.0 ET_DYN /usr/lib64/qt4 /usr/lib/qt4/libQtDBus.so.4.3.0 ET_DYN /usr/lib64/qt4 /usr/lib/qt4/libQtCore.so.4.3.0 ET_DYN /usr/lib64/qt4 /usr/lib/qt4/libQtSql.so.4.3.0 ET_DYN /usr/lib64/qt4 /usr/lib/qt4/libQtGui.so.4.3.0 ET_DYN /usr/lib64/qt4 /usr/lib/qt4/libQtDesignerComponents.so.4.3.0 ET_DYN /usr/lib64/qt4 /usr/lib/qt4/libQtAssistantClient.so.4.3.0 ET_DYN /usr/lib64/qt4 /usr/lib/qt4/libQtSvg.so.4.3.0 ET_DYN /usr/lib64/qt4 /usr/lib/qt4/libQtNetwork.so.4.3.0 Do you think it's safe to re-enable rpath support?
Is there any advantage to using rpath? IIRC, the main reason we got rid of it was when doing a version upgrade of Qt, it was finding and linking against the one that was already installed on the system, causing upgrades to fail. This may be fixed and may not be an issue anymore, but it might be worthwhile to test.
rpath *should* make it faster for the runtime linker to find the correct library to use; but if it's getting a problem during upgrade (it might if the ld params are not used correctly) it's probably not worth to fix it. The comments on the ebuild only refers to a security bug that now shouldn't apply anymore (so those parts should probably be removed, especially since -no-rpath takes care of it without seds).
I think one other issue we were having was that it was setting the wrong rpath in early 4.x builds. It would set it to the build directory instead of the install directory. I'm guessing TT has gotten that sorted out since, though.
# gentoo-x86 relies on ld.so.conf to get the correct LDPATH, Gentoo # Prefix can't do that, so use don't explicitly set RPATH and hence use # the defaults - which works and is desired in this case. #QMAKE_RPATH= \
in other words, we (Prefix team) would like to see -no-rpath go from qt4-build.eclass
Building qt-*-4.6.0_beta1 with RPATH enabled leads to: TYPE RPATH FILE ET_DYN /usr/lib64/qt4 ./libQtSql.so ET_DYN /usr/lib64/qt4 ./libQtWebKit.so ET_DYN /usr/lib64/qt4 ./libQtDesignerComponents.so ET_DYN /usr/lib64/qt4 ./libQtNetwork.so ET_DYN /usr/lib64/qt4 ./plugins/designer/libqwebview.so ET_DYN /usr/lib64/qt4 ./plugins/designer/libqt3supportwidgets.so ET_DYN /usr/lib64/qt4 ./plugins/accessible/libqtaccessiblewidgets.so ET_DYN /usr/lib64/qt4 ./plugins/imageformats/libqgif.so ET_DYN /usr/lib64/qt4 ./plugins/imageformats/libqico.so ET_DYN /usr/lib64/qt4 ./plugins/imageformats/libqjpeg.so ET_DYN /usr/lib64/qt4 ./plugins/imageformats/libqsvg.so ET_DYN /usr/lib64/qt4 ./plugins/imageformats/libqtiff.so ET_DYN /usr/lib64/qt4 ./plugins/iconengines/libqsvgicon.so ET_DYN /usr/lib64/qt4 ./plugins/sqldrivers/libqsqlite.so ET_DYN /usr/lib64/qt4 ./plugins/inputmethods/libqimsw-multi.so ET_DYN /usr/lib64/qt4 ./plugins/codecs/libqjpcodecs.so ET_DYN /usr/lib64/qt4 ./plugins/codecs/libqcncodecs.so ET_DYN /usr/lib64/qt4 ./plugins/codecs/libqkrcodecs.so ET_DYN /usr/lib64/qt4 ./plugins/codecs/libqtwcodecs.so ET_DYN /usr/lib64/qt4 ./plugins/graphicssystems/libqglgraphicssystem.so ET_DYN /usr/lib64/qt4 ./libQtTest.so ET_DYN /usr/lib64/qt4 ./libQtSvg.so ET_DYN /usr/lib64/qt4 ./libQtDBus.so ET_DYN /usr/lib64/qt4 ./libQtXml.so ET_DYN /usr/lib64/qt4 ./libQtDesigner.so ET_DYN /usr/lib64/qt4 ./libQtOpenGL.so ET_DYN /usr/lib64/qt4 ./libQtCore.so ET_DYN /usr/lib64/qt4 ./libQtScriptTools.so ET_DYN /usr/lib64/qt4 ./libQtXmlPatterns.so ET_DYN /usr/lib64/qt4 ./libQt3Support.so ET_DYN /usr/lib64/qt4 ./libQtScript.so ET_DYN /usr/lib64/qt4 ./libQtGui.so Then, rebuilding qt-core-4.5.3-r2 with RPATH leads to: TYPE RPATH FILE ET_DYN /usr/lib64/qt4 libQtCore.so.4.5.3 And of course rebuilding qt-core-4.6.0_beta1 works as well. Everything seems to work well so enabling RPATH is probably the way to go, assuming there are no security issues. Note that this means we should also remove the "QMAKE_RPATH= \" line from qt4.eclass, as grobian said.
Changes to qt4-build.eclass and qt4.eclass committed, as per yngwin's approval. Thank you all :)
