Version: unspecified (using KDE 4.7.0) OS: MS Windows When opening an application which requires Qt plugins (e.g. database plugins) it fails to load those plugins because they are seemingly at the wrong location. Reproducible: Didn't try Steps to Reproduce: open digikam Actual Results: fails due to missing database plugins Expected Results: digikam loads the available plugins work around: copying the plugins from %KDEROOT%\plugins\sqldrivers\* to %KDEROOT%\bin\sqldrivers will make it work. This is none-sense though, since the plugin destination hasn't changed.
Maybe the parameters to 'configure' when building Qt are different? This can be solved easily by providing a qt.conf http://doc.qt.nokia.com/latest/qt-conf.html
hm, actually we already provide a qt.conf ... but this might be the issue. Thanks for providing this info.
qt sqldrivers are installed into <root>/plugins/sqldrivers, but they are expected at <root>/bin/sqldrivers. I encountered this problem also in another project using qt 4.7.0 without a qt.conf
well, I checked it, and qt.conf is at the correct place but isn't read at all (checked with procmon)... I probably need to read the qt code again when the search for qt.conf is suppressed.
*** Bug 281493 has been marked as a duplicate of this bug. ***
ok, I am pretty sure this is the issue: https://bugreports.qt.nokia.com//browse/QTSDK-630 I will rebuild Qt and update it to 4.7.4 this week, and as a hotfix also change the default path. This won't help in the future though, since this definitely breaks our builds - we need to find out which global static object breaks this.
in qlibraryinfo.cpp there is the following code: QSettings *QLibraryInfoPrivate::findConfiguration() { QString qtconfig = QLatin1String(":/qt/etc/qt.conf"); #ifdef BOOTSTRAPPING if(!QFile::exists(qtconfig)) qtconfig = qmake_libraryInfoFile(); #else if (!QFile::exists(qtconfig) && QCoreApplication::instance()) { It looks to me, that defining -DBOOTSTRAPPING should reenbale the known behavior.
Ok, I added debug packages to our Qt now, and what I found is this: the first call of the findConfiguration function has this backtrace: QtCore4!QLibraryInfoPrivate::findConfiguration+0x44 QtCore4!QLibrarySettings::QLibrarySettings+0x2b QtCore4!qt_library_settings+0x5c QtCore4!QLibraryInfo::location+0x61 QtCore4!QCoreApplication::libraryPaths+0xa3 QtCore4!QCoreApplication::addLibraryPath+0x65 kdecore!KComponentDataPrivate::lazyInit+0x163 kdecore!KComponentData::dirs+0xc kdecore!KConfigPrivate::KConfigPrivate+0x12c kdecore!KConfig::KConfig+0x73 kdecore!KSharedConfig::KSharedConfig+0x4b kdecore!KSharedConfig::openConfig+0x138 kdecore!KComponentDataPrivate::configInit+0x1b6 kdecore!KComponentDataPrivate::lazyInit+0xfd kdecore!KComponentData::KComponentData+0x7a kdeui!KUniqueApplication::Private::initHack+0x43 kdeui!KUniqueApplication::KUniqueApplication+0x3a skgbasegui!SKGUniqueApplication::SKGUniqueApplication+0x33 skrooge!main+0x787 skrooge!WinMain+0x105 This means especially that the QCoreApplication instance which would be added *after* the initHack of the KUniqueApplication::Private will not be there. This also means that the code for the external qt.conf will never be called.
Qt plugins work fine with current craft build stuff.