Bug 56723 – [Qt] Linking error when tryng to build Qt Webkit on Windows

• Component: New Bugs
• Status: RESOLVED FIXED

[Nancy Piedra]

Created attachment 86281 [details]
Windows XP linking errors

When trying to build Qt Webkit on Windows XP using MinGW, I get linking errors.  I've attached the error output.

I looked through exiting bugs and didn't see one for this.

I followed the instruction here and built using MinGW:
http://trac.webkit.org/wiki/BuildingQtOnWindows

[Nancy Piedra]

To determine whether the problem is due to the setting of the QWEBKIT_EXPORT macro, I added the following two lines to qwebkitglobal.h.
#define QT_MAKEDLL
#define BUILDING_WEBKIT

By doing the above, I was able to get it to link.

But I could not figure out how to set these through the .pro/pri files properly.  Still working on that.

[Nancy Piedra]

The log shows I used c:\Qt\2010.05 but the same problem exists with C:\Qt\4.7.2.

[Nancy Piedra]

Created attachment 86286 [details]
Change to qwebkitglobal.h

This change seems to fix the problem.  Need to check other builds to make sure it doesn't cause any regression.

[Nancy Piedra]

After speaking with Laszlo Gombos, this seems like qt layering violations we may be able to fix.  I will start looking at that and seeing if I can instead submit patches for the layering violations.

[Laszlo Gombos]

*** Bug 55050 has been marked as a duplicate of this bug. ***

[Nancy Piedra]

Created attachment 86760 [details]
Change to webcore.pro to export qtwebkit symbols

This patch sets the BUILDING_WEBKIT & QT_MAKEDLL macros which in turn will define the QTWEBKIT_EXPORT macro as follows:
#define QWEBKIT_EXPORT Q_DECL_EXPORT

This patch also solves the problem.

[Andras Becsi]

(In reply to comment #6)
> Created an attachment (id=86760) [details]
> Change to webcore.pro to export qtwebkit symbols
> 
> This patch sets the BUILDING_WEBKIT & QT_MAKEDLL macros which in turn will define the QTWEBKIT_EXPORT macro as follows:
> #define QWEBKIT_EXPORT Q_DECL_EXPORT
> 
> This patch also solves the problem.

LGTM.

Ossy could you check whether this also works on your setup?


Nancy, please upload a patch with a ChangeLog for the change and set the r? flag if you'd like the patch to get into trunk and to let the EWS' process it.

For more information see: http://trac.webkit.org/wiki/QtWebKitContrib

[Csaba Osztrogonác]

I tried it, and it works on my Windows machine with MinGW.

Laszlo, have you got any objection against Nancy's fix? 
(apart from missing ChangeLog)

[Nancy Piedra]

Created attachment 86943 [details]
Fixes linking errors in Qt Webkit Windows MinGW build.

Add patch for review.

[Joseph Tsai]

Created attachment 87075 [details]
Link error while --3d-canvas option is enabled

(In reply to comment #9)
> Created an attachment (id=86943) [details]
> Fixes linking errors in Qt Webkit Windows MinGW build.

For building QtWebKit with applying Nancy's patch and WebGL supported (by enabling --3d-canvas option), other undefined references occur again. These undefined references are all about OpenGL functions. (i.e. glDeleteTextures@8)

After digging in the building process, I found that these undefined references should be declared in -lopengl32 option (mingw/lib/libopengl32.a). When building QtWebKit4.dll, the linking option -lopengl32 is before -lwebcore, and the undefined references in libwebcore.a miss their linkage.

For quick workaround, I appended -lopengl32 behind the LIBS variable in Source/WebCore/WebCore.pri:

--------------------------------------
--- WebCore.pri.orig	2011-03-26 18:01:54.000000000 +0800
+++ WebCore.pri	2011-03-27 23:51:14.000000000 +0800
@@ -368,7 +368,7 @@
         POST_TARGETDEPS += $${pathToWebCoreOutput}$${QMAKE_DIR_SEP}$${WEBCORE_TARGET}.lib
     } else {
         QMAKE_LIBDIR = $$pathToWebCoreOutput $$QMAKE_LIBDIR
-        LIBS = -l$$WEBCORE_TARGET $$LIBS
+        LIBS = -l$$WEBCORE_TARGET $$LIBS -lopengl32
         POST_TARGETDEPS += $${pathToWebCoreOutput}$${QMAKE_DIR_SEP}lib$${WEBCORE_TARGET}.a
     }
--------------------------------------

And the building is passed.

[Joseph Tsai]

> For building QtWebKit with applying Nancy's patch and WebGL supported (by enabling --3d-canvas option), other undefined references occur again. These undefined references are all about OpenGL functions. (i.e. glDeleteTextures@8)

The building command that I used:

perl Tools\Scripts\build-webkit --qt --3d-canvas --release

[Csaba Osztrogonác]

Comment on attachment 86943 [details]
Fixes linking errors in Qt Webkit Windows MinGW build.

r=me

[Csaba Osztrogonác]

Comment on attachment 86943 [details]
Fixes linking errors in Qt Webkit Windows MinGW build.

Landed in http://trac.webkit.org/changeset/82102.

Please don't forget to add bug number to the ChangeLog next time.

[Nancy Piedra]

(In reply to comment #11)
> > For building QtWebKit with applying Nancy's patch and WebGL supported (by enabling --3d-canvas option), other undefined references occur again. These undefined references are all about OpenGL functions. (i.e. glDeleteTextures@8)
> The building command that I used:
> perl Tools\Scripts\build-webkit --qt --3d-canvas --release

Joseph - I can create a separate bug for this and see about fixing it.  If you already created the bug, let me know the number.

[Joseph Tsai]

(In reply to comment #14)
> (In reply to comment #11)
> > The building command that I used:
> > perl Tools\Scripts\build-webkit --qt --3d-canvas --release
> 
> Joseph - I can create a separate bug for this and see about fixing it.  If you already created the bug, let me know the number.

I have not created any bug report about this issue yet.

[Andras Becsi]

(In reply to comment #14)
> (In reply to comment #11)
> > > For building QtWebKit with applying Nancy's patch and WebGL supported (by enabling --3d-canvas option), other undefined references occur again. These undefined references are all about OpenGL functions. (i.e. glDeleteTextures@8)
> > The building command that I used:
> > perl Tools\Scripts\build-webkit --qt --3d-canvas --release
> 
> Joseph - I can create a separate bug for this and see about fixing it.  If you already created the bug, let me know the number.

I already created one and am preparing a patch for the issue:

https://bugs.webkit.org/show_bug.cgi?id=57225