Summary: | [Qt] DRT shouldn't link against libQtWebKit inside Qt | ||
---|---|---|---|
Product: | WebKit | Reporter: | Csaba Osztrogonác <ossy> |
Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Blocker | CC: | benjamin, hausmann, ossy, sam, vestbo |
Priority: | P1 | Keywords: | Qt, QtTriaged |
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All |
Description
Csaba Osztrogonác
2012-09-25 00:47:26 PDT
r129444 is absolutely innocent, Simon pointed out the root of the bug. DRT links against libQtWebKit inside Qt, but it should link against the libQtWebKit built from WebKit trunk. So the bug is somewhere in the buildsystem of Qt/QtWebKit. Now we use a custom built Qt 5.0 beta1 on the Windows bot without building QtWebKit in it as workaround. Tor Arne, I think this is similar to the qt_webkit.pri file caching issue we discussed with Ossi a few days ago. Apart from the cache bug in qmake, the type of build is according to Ossi not officially supported, i.e. having built WebKit once as a module in Qt requires the deletion of $qtbase/mkspecs/modules/qt_webkit.pri _prior_ to subsequent builds of WebKit from a different build location. We could implement this in build-webkit as a safety belt, i.e. if Qt is a developer-build, remove the qt_webkit.pri file from $qtbase before starting the build. Kind of a hack :) === Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary. If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines. |