Bug 102057

Summary: Cannot compile QtWebKit 2.3 on Mac
Product: WebKit Reporter: Bobber <bobber.cheng>
Component: WebKit QtAssignee: 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    

Description Bobber 2012-11-13 00:46:01 PST
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
Comment 1 Bobber 2012-11-13 01:11:18 PST
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.
Comment 2 Zeno Albisser 2012-11-13 02:02:25 PST
(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.
Comment 3 Allan Sandfeld Jensen 2012-11-13 03:10:24 PST
(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.
Comment 4 Allan Sandfeld Jensen 2012-11-19 02:45:06 PST
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.
Comment 5 Bobber 2012-11-23 01:27:30 PST
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
Comment 6 Allan Sandfeld Jensen 2012-11-23 02:22:33 PST
(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?
Comment 7 Allan Sandfeld Jensen 2013-04-18 02:38:11 PDT
Yes, that last change is needed as well, no matter if I understand it or not.
Comment 8 Allan Sandfeld Jensen 2013-04-18 05:41:52 PDT
(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.
Comment 9 Bobber 2013-04-18 21:56:08 PDT
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.
Comment 10 Allan Sandfeld Jensen 2013-04-19 07:38:13 PDT
(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' ?
Comment 11 Allan Sandfeld Jensen 2013-04-19 07:38:29 PDT
(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
Comment 12 Bobber 2013-04-21 20:31:19 PDT
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
Comment 13 Allan Sandfeld Jensen 2013-04-22 02:30:35 PDT
(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.
Comment 14 Tobias Netzel 2013-06-18 15:30:37 PDT
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.
Comment 15 Tobias Netzel 2013-06-25 13:42:23 PDT
Bug 118001 is my bug about adoptCF() being called on the result of createCFString().
Comment 16 Brent Fulgham 2014-01-09 21:06:03 PST
The QT port is no longer part of WebKit.