Bug 102057
Summary: | Cannot compile QtWebKit 2.3 on Mac | ||
---|---|---|---|
Product: | WebKit | Reporter: | Bobber <bobber.cheng> |
Component: | WebKit Qt | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Blocker | CC: | allan.jensen, bfulgham, tobias.netzel, zeno |
Priority: | P1 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Mac (Intel) | ||
OS: | OS X 10.7 | ||
Bug Depends on: | |||
Bug Blocks: | 88186 |
Bobber
Cannot compile QtWebKit 2.3 on Mac due to dependency of qt5 in following files:
Source/WebCore/platform/graphics/qt/GraphicsContext3DQt.cpp
Source/WebCore/platform/graphics/surfaces/mac/GraphicsSurfaceMac.cpp
Source/WebCore/platform/graphics/surfaces/qt/GraphicsSurfaceQt.cpp
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Bobber
When compling with --debug after removing dependecy of qt5, got following error.
/usr/bin/ranlib: archive member: libWebCore.a(JSTreeWalkerCustom.o) size too large (archive member extends past the end of the file)
ar: internal ranlib command failed
$ ls -lh WebKitBuild/Debug/Source/WebCore/libWebCore.a
-rw-r--r-- 1 set staff 4.3G Nov 13 17:03 WebKitBuild/Debug/Source/WebCore/libWebCore.a
refer to https://bugreports.qt-project.org/browse/QTBUG-20619.
Zeno Albisser
(In reply to comment #1)
> When compling with --debug after removing dependecy of qt5, got following error.
>
> /usr/bin/ranlib: archive member: libWebCore.a(JSTreeWalkerCustom.o) size too large (archive member extends past the end of the file)
> ar: internal ranlib command failed
Which version of XCode (command line tools) do you use?
You get this error because your archive libWebCore.a is getting bigger than 4GB.
This was a bug in the Mac tool chain (libtool).
You might need to update these. This bug has been fixed in XCode 4.4.1.
Allan Sandfeld Jensen
(In reply to comment #0)
> Cannot compile QtWebKit 2.3 on Mac due to dependency of qt5 in following files:
> Source/WebCore/platform/graphics/qt/GraphicsContext3DQt.cpp
> Source/WebCore/platform/graphics/surfaces/mac/GraphicsSurfaceMac.cpp
> Source/WebCore/platform/graphics/surfaces/qt/GraphicsSurfaceQt.cpp
You can work around this by in Tools/qmake/mkspecs/features/features.prf commenting out the line "mac: DEFINES += WTF_USE_GRAPHICS_SURFACE=1". Until those files have been ported (if even possible), I gues we do not support "graphics surface" in QtWebKit 2.3.
I guess we will have the same problem on win32, though only if Qt has been configured with opengles2.
Allan Sandfeld Jensen
I have made graphics surface depend on Qt5. The code looks portable, but it will require some testing and one or two work-arounds, so disabling it for now seems better since it is a new feature anyway.
Bobber
Hi Allan,
Your change is good, but there is new compiling error for Source/WebCore/plugins/mac/PluginPackageMac.cpp. Please make following change to compile it:
WTF::RetainPtr<CFStringRef> homeDir = adoptCF(homeDirectoryPath().createCFString());
to
WTF::RetainPtr<CFStringRef> homeDir(homeDirectoryPath().createCFString());
WTF::RetainPtr<CFStringRef> path(AdoptCF, m_path.createCFString());
to
WTF::RetainPtr<CFStringRef> path(m_path.createCFString());
Thanks,
Bobber
Allan Sandfeld Jensen
(In reply to comment #5)
> WTF::RetainPtr<CFStringRef> path(AdoptCF, m_path.createCFString());
> to
> WTF::RetainPtr<CFStringRef> path(m_path.createCFString());
>
I don't understand this change. The constructor pattern WTF::RetainPtr<CFStringRef> (AdoptCF, CFString) is used everywhere. Why would this one place cause compile error when the rest does not?
Allan Sandfeld Jensen
Yes, that last change is needed as well, no matter if I understand it or not.
Allan Sandfeld Jensen
(In reply to comment #7)
> Yes, that last change is needed as well, no matter if I understand it or not.
Fixed in the upcoming 2.3.2.
Bobber
Release version is ok now, but I still cannot compile debug version On Mac even with clang or XCode 4.6.2. Errow is that archive libWebCore.a is getting bigger than 4GB.
Allan Sandfeld Jensen
(In reply to comment #9)
> Release version is ok now, but I still cannot compile debug version On Mac even with clang or XCode 4.6.2. Errow is that archive libWebCore.a is getting bigger than 4GB.
Does it help if you build with -qmake='CONFIG+=production_build' ?
Allan Sandfeld Jensen
(In reply to comment #10)
> (In reply to comment #9)
> > Release version is ok now, but I still cannot compile debug version On Mac even with clang or XCode 4.6.2. Errow is that archive libWebCore.a is getting bigger than 4GB.
>
> Does it help if you build with -qmake='CONFIG+=production_build' ?
sorry -qmakearg
Bobber
Thanks for your advise, Allan. But -qmake='CONFIG+=production_build' still doesn't reduce libWebCore.a less 4GB. Here is detail:
$ Tools/Scripts/build-webkit --qt --no-video --no-sql-database --no-icon-database --no-webgl --no-3d-rendering --makeargs="-j4" --debug --no-webkit2 --qmakearg="CONFIG+=production_build" -spec unsupported/macx-clang
.....
/usr/bin/ranlib: archive: libWebCore.a truncated or malformed (archive header of next member extends past the end of the file)
ar: internal ranlib command failed
make[3]: *** [debug/libWebCore.a] Error 1
make[2]: *** [sub-Target-pri-make_default-ordered] Error 2
make[1]: *** [sub-Source-WebCore-WebCore-pro-make_default-ordered] Error 2
make: *** [incremental] Error 2
$ ls -lh WebKitBuild/Debug/Source/WebCore/libWebCore.a
-rw-r--r-- 1 set staff 4.3G Apr 22 11:20 WebKitBuild/Debug/Source/WebCore/libWebCore.a
Allan Sandfeld Jensen
(In reply to comment #12)
> Thanks for your advise, Allan. But -qmake='CONFIG+=production_build' still doesn't reduce libWebCore.a less 4GB. Here is detail:
>
> $ Tools/Scripts/build-webkit --qt --no-video --no-sql-database --no-icon-database --no-webgl --no-3d-rendering --makeargs="-j4" --debug --no-webkit2 --qmakearg="CONFIG+=production_build" -spec unsupported/macx-clang
> .....
> /usr/bin/ranlib: archive: libWebCore.a truncated or malformed (archive header of next member extends past the end of the file)
> ar: internal ranlib command failed
> make[3]: *** [debug/libWebCore.a] Error 1
> make[2]: *** [sub-Target-pri-make_default-ordered] Error 2
> make[1]: *** [sub-Source-WebCore-WebCore-pro-make_default-ordered] Error 2
> make: *** [incremental] Error 2
>
> $ ls -lh WebKitBuild/Debug/Source/WebCore/libWebCore.a
> -rw-r--r-- 1 set staff 4.3G Apr 22 11:20 WebKitBuild/Debug/Source/WebCore/libWebCore.a
Ah, so you get around the problem with ANGLE by disabling 3d-rendering.
This bug though, still sounds like libWebCore.a ends up larger than 4Gbyte.
Tobias Netzel
I can explain why the adoptCF / createCFString patch is needed (reading about that here reminds me that I've still got to file the bug with a fix for that; when I wanted to file it WebKit bugzilla was offline).
createCFString at some point in the past was changed to already return an object of type WTF::RetainPtr<CFStringRef> so all code that called adoptCF() on the return value of createCFString() should have been changed to omit the call to adoptCF(), but it was obviously forgotten. That construct in my case led to crashes because it made the ObjC garbage collector destroy the String shortly after the call, leading to subsequent crashes when trying to access that String.
Tobias Netzel
Bug 118001 is my bug about adoptCF() being called on the result of createCFString().
Brent Fulgham
The QT port is no longer part of WebKit.