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 |
Description
Bobber
2012-11-13 00:46:01 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. (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. (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. 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. 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 (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? Yes, that last change is needed as well, no matter if I understand it or not. (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. 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. (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' ? (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 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 (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. 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. Bug 118001 is my bug about adoptCF() being called on the result of createCFString(). The QT port is no longer part of WebKit. |