Bug 39054

Created attachment 55960 [details] Proposed patch

Comment on attachment 55960 [details] Proposed patch WebKit/chromium/WebKit.gyp:607 + '<(chromium_src_dir)/webkit/tools/test_shell/resources/textAreaResizeCorner.png', We probably shouldn't reach into a Chromium checkout here, right?

(In reply to comment #2) > (From update of attachment 55960 [details]) > WebKit/chromium/WebKit.gyp:607 > + '<(chromium_src_dir)/webkit/tools/test_shell/resources/textAreaResizeCorner.png', > We probably shouldn't reach into a Chromium checkout here, right? I see. This path seems very specific and we had better avoid it. So we shoud ... - Copy textAreaResizeCorner.png to SHARED_INTERMEDIATE_DIR in webkit_support.gyp - WebKit.gyp refer to SHARED_INTERMEDIATE_DIR

Sounds good.

Created attachment 56059 [details] Proposed patch (rev.2)

> - Copy textAreaResizeCorner.png to SHARED_INTERMEDIATE_DIR in webkit_support.gyp This was done by Chromium r47248.

Comment on attachment 56059 [details] Proposed patch (rev.2) Thank you so much!

Attachment 56059 [details] was posted by a committer and has review+, assigning to Kent Tamura for commit.

Comment on attachment 56059 [details] Proposed patch (rev.2) I have a bad feeling about this patch, but let's give it a go.

Comment on attachment 56059 [details] Proposed patch (rev.2) Clearing flags on attachment: 56059 Committed r59571: <http://trac.webkit.org/changeset/59571>

All reviewed patches have been landed. Closing bug.

I think this broke cr win but due to dependency issues we did not notice until one commit later.

Yes, I believe we hit https://bugs.webkit.org/show_bug.cgi?id=38926, which caused this to not fail immediately after checkin but rather after the next change which caused a larger rebuild.

Actually, I think this break might just be a symptom of https://bugs.webkit.org/show_bug.cgi?id=38926 directly. It's possible with a full rebuild that CrDRT would build just fine... not sure? 12> Creating library C:\WebKitBuildSlave\chromium-win-release\build\WebKit\chromium\Release\lib\DumpRenderTree.lib and object C:\WebKitBuildSlave\chromium-win-release\build\WebKit\chromium\Release\lib\DumpRenderTree.exp 12>webcore_bindings.lib(V8DerivedSources3.obj) : error LNK2019: unresolved external symbol "public: __thiscall WebCore::ArrayBuffer::~ArrayBuffer(void)" (??1ArrayBuffer@WebCore@@QAE@XZ) referenced in function "public: void * __thiscall WebCore::ArrayBuffer::`scalar deleting destructor'(unsigned int)" (??_GArrayBuffer@WebCore@@QAEPAXI@Z) 12>webcore_bindings.lib(V8DerivedSources6.obj) : error LNK2001: unresolved external symbol "public: __thiscall WebCore::ArrayBuffer::~ArrayBuffer(void)" (??1ArrayBuffer@WebCore@@QAE@XZ) 12>webcore_bindings.lib(V8DerivedSources3.obj) : error LNK2019: unresolved external symbol "public: unsigned int __thiscall WebCore::ArrayBuffer::byteLength(void)const " (?byteLength@ArrayBuffer@WebCore@@QBEIXZ) referenced in function "class v8::Handle<class v8::Value> __cdecl WebCore::ArrayBufferInternal::byteLengthAttrGetter(class v8::Local<class v8::String>,class v8::AccessorInfo const &)" (?byteLengthAttrGetter@ArrayBufferInternal@WebCore@@YA?AV?$Handle@VValue@v8@@@v8@@V?$Local@VString@v8@@@4@ABVAccessorInfo@4@@Z) 12>webcore_bindings.lib(V8DerivedSources3.obj) : error LNK2019: unresolved external symbol "public: static class v8::Handle<class v8::Value> __cdecl WebCore::V8ArrayBuffer::constructorCallback(class v8::Arguments const &)" (?constructorCallback@V8ArrayBuffer@WebCore@@SA?AV?$Handle@VValue@v8@@@v8@@ABVArguments@4@@Z) referenced in function "class v8::Persistent<class v8::FunctionTemplate> __cdecl WebCore::ConfigureV8ArrayBufferTemplate(class v8::Persistent<class v8::FunctionTemplate>)" (?ConfigureV8ArrayBufferTemplate@WebCore@@YA?AV?$Persistent@VFunctionTemplate@v8@@@v8@@V23@@Z)

I seem to be unable to get the cr win builder to do a clean build (using the abort during the svn update step trick). So I"m going to roll this out in hopes of re-greening the tree.

Reverted r59571 for reason: Broke Cr Win, but we didn't notice immediately due to https://bugs.webkit.org/show_bug.cgi?id=38926. It's possible that this didn't actually break Cr Win, but rather that bug 38926 necessitates a clean compile after this and sucessive checkins only produced a partial recompile and thus failed to build. Committed r59578: <http://trac.webkit.org/changeset/59578>

Basically, I wasn't able to sort this out myself on the bots. Someone with a Cr Win checkout will need to take a look and either hack around bug 38926 or simply fix it when landing this again. :)

We added a workaround for the features change issue. I'll re-land the patch of this bug.

I landed as r59650, and reverted it as r59651. The workaround didn't work well.

I'll land the patch without the features.gypi change.

Landed as r59744.