[Webkit-unassigned] [Bug 68206] Ensure TestWebKitAPI works on mac, win, chromium-mac, chromium-win and chromium-linux

[bugzilla-daemon at webkit.org]

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





--- Comment #3 from Xianzhu Wang <wangxianzhu at chromium.org>  2011-09-15 20:59:26 PST ---
(In reply to comment #2)

Thanks Dirk for detailed and helpful explanation.

I just tried component=shared_library in a WebKit source tree with chromium dependencies on Linux, and encountered linking errors:

/usr/bin/ld: out/Release/obj.target/DumpRenderTree/Tools/DumpRenderTree/chromium/TestShell.o: in function TestShell::bindJSObjectsToWindow(WebKit::WebFrame*):TestShell.cpp(.text._ZN9TestShell21bindJSObjectsToWindowEPN6WebKit8WebFrameE+0x17): error: undefined reference to 'WebKit::WebTestingSupport::injectInternalsObject(WebKit::WebFrame*)'
/usr/bin/ld: out/Release/obj.target/DumpRenderTree/Tools/DumpRenderTree/chromium/TestShell.o: in function TestShell::resetTestController():TestShell.cpp(.text._ZN9TestShell19resetTestControllerEv+0x132): error: undefined reference to 'WebKit::WebTestingSupport::resetInternalsObject(WebKit::WebFrame*)'

I tried to fix it by moving the 'component=="shared_library"' condition out of 'inside_chromium_build==1' condition (WebKit.gyp about line 619), and I can successfully build all targets.

Is it intended that component=shared_library doesn't work for 'build-wekit --chromium'?

BTW do you know what Source/WebCore/gyp/WebCore.gyp (not .../WebCore.gyp/WebCore.gyp) and Source/JavaScriptCore/gyp/JavaScriptCore.gyp are for?

> Okay, I spent a half hour or so staring at this on the win shared build and I think you've got a couple of things to fix before this'll work.
> 
> this TestWebKitAPI target is new to me ... it looks like it is intended to be the unit test driver for c++ tests in webkit/webcore/etc.?
> 

I think so. However, for now it contains only tests for WTF and WebKit2. I touched this because I'm making some changes to WTF::StringBuilder and want unit tests for it.

> At any rate, it appears to be linking in both webkit and wtf, and it looks like the existing files for TestWebKitAPI are unit tests for WTF ...
> 
> Here's where the problems come up ... Chromium is only building wtf as a static library; it gets included into webkit.dll, but the WTF symbols aren't (and shouldn't be) exported from that. 
> 
> the WTF library has internal dependencies on a function called currentTime; Chromium overrides the default WTF implementation with one found in ChromiumCurrentTime. Which, unfortunately, is not built as part of wtf.lib, it's built as part of webkit.dll. 
> 
> So, wtf can't link without webkit.dll. However, there's no good way to export the CurrentTime symbol out of webkit.dll on windows in a way where the __declspec(dllexport) makes sense, without creating a compile time dependency from wtf onto webkit.
> 
> You can hack around this by including ChromiumCurrentTime.cpp and ChromiumThreading.cpp (apparently also needed) directly into the TestWebKitAPI sources list, but of course you can't call the currentTime function() without initializing webkit_support and including that as a dependency.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.