| Summary: | Qt plugins cannot be found. | ||
|---|---|---|---|
| Product: | [Unmaintained] kde-windows | Reporter: | Patrick Spendrin <ps_ml> |
| Component: | general | Assignee: | KDE-Windows <kde-windows> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | agm.alistairgg, christoph, KD6PAG, ps_ml, ralf.habacker |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Patrick Spendrin
2011-09-04 18:21:06 UTC
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. |