Bug 97536 - [Qt] DRT shouldn't link against libQtWebKit inside Qt
Summary: [Qt] DRT shouldn't link against libQtWebKit inside Qt
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P1 Blocker
Assignee: Nobody
URL:
Keywords: Qt, QtTriaged
Depends on:
Blocks:
 
Reported: 2012-09-25 00:47 PDT by Csaba Osztrogonác
Modified: 2014-02-03 03:22 PST (History)
5 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Csaba Osztrogonác 2012-09-25 00:47:26 PDT 
I have no idea how is it possible, but after r129444 
linking of DRT fails with the following DRT link error:

	link /NOLOGO /DYNAMICBASE /NXCOMPAT /INCREMENTAL:NO /SUBSYSTEM:CONSOLE "/MANIFESTDEPENDENCY:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" /MANIFEST /MANIFESTFILE:..\..\..\bin\DumpRenderTree.exe.embed.manifest /OUT:..\..\..\bin\DumpRenderTree.exe @C:\Users\WEBKIT~1\AppData\Local\Temp\nmEC57.tmp
TestRunnerQt.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static void __cdecl DumpRenderTreeSupportQt::setMockGeolocationPositionUnavailableError(class QWebPage *,class QString const &)" (__imp_?setMockGeolocationPositionUnavailableError@DumpRenderTreeSupportQt@@SAXPAVQWebPage@@ABVQString@@@Z) referenced in function "public: void __thiscall TestRunner::setMockGeolocationPositionUnavailableError(class QString const &)" (?setMockGeolocationPositionUnavailableError@TestRunner@@QAEXABVQString@@@Z)
..\..\..\bin\DumpRenderTree.exe : fatal error LNK1120: 1 unresolved externals
Comment 1 Csaba Osztrogonác 2012-09-25 07:18:27 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.
Comment 2 Simon Hausmann 2012-09-25 07:30:41 PDT 
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 :)
Comment 3 Jocelyn Turcotte 2014-02-03 03:22:49 PST 
=== 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.