Bug 172267 - [Win] error LNK2005: WebCore::JSNode::checkSubClassPatchpoint() already defined in WebKit.lib
Summary: [Win] error LNK2005: WebCore::JSNode::checkSubClassPatchpoint() already defin...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Fujii Hironori
URL:
Keywords:
Depends on: 172098
Blocks:
  Show dependency treegraph
 
Reported: 2017-05-18 03:11 PDT by Fujii Hironori
Modified: 2017-05-19 23:55 PDT (History)
5 users (show)

See Also:


Attachments
WIP patch (985 bytes, patch)
2017-05-19 01:50 PDT, Fujii Hironori
no flags Details | Formatted Diff | Diff
Patch (4.30 KB, patch)
2017-05-19 02:47 PDT, Fujii Hironori
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Fujii Hironori 2017-05-18 03:11:23 PDT
AppleWin port and WinCairo port builds are broken.

> FAILED: bin64/TestWebKitLib.dll lib64/TestWebKitLib.lib 
> cmd.exe /C "cd . && C:\tools\cmake\bin\cmake.exe -E vs_link_dll --intdir=Tools\TestWebKitAPI\CMakeFiles\TestWebKitLib.dir --manifests  -- "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\link.exe" /nologo @CMakeFiles/TestWebKitLib.rsp  /out:bin64\TestWebKitLib.dll /implib:lib64\TestWebKitLib.lib /pdb:bin64\TestWebKitLib.pdb /dll /version:0.0 /machine:x64 /DEBUG /OPT:ICF /OPT:REF /INCREMENTAL:NO   && cd ."
> WebCore.lib(JSNodeDOMJIT.cpp.obj) : error LNK2005: "public: static class WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl WebCore::JSNode::checkSubClassPatchpoint(void)" (?checkSubClassPatchpoint@JSNode@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
> 
> WebCore.lib(JSDocumentDOMJIT.cpp.obj) : error LNK2005: "public: static class WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl WebCore::JSDocument::checkSubClassPatchpoint(void)" (?checkSubClassPatchpoint@JSDocument@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
> 
>    Creating library lib64\TestWebKitLib.lib and object lib64\TestWebKitLib.exp
> 
> bin64\TestWebKitLib.dll : fatal error LNK1169: one or more multiply defined symbols found
> 
> LINK failed. with 1169
> [60/60] Linking CXX shared library bin64\TestWebCoreLib.dll
> FAILED: bin64/TestWebCoreLib.dll lib64/TestWebCoreLib.lib 
> cmd.exe /C "cd . && C:\tools\cmake\bin\cmake.exe -E vs_link_dll --intdir=Tools\TestWebKitAPI\CMakeFiles\TestWebCoreLib.dir --manifests  -- "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\link.exe" /nologo @CMakeFiles/TestWebCoreLib.rsp  /out:bin64\TestWebCoreLib.dll /implib:lib64\TestWebCoreLib.lib /pdb:bin64\TestWebCoreLib.pdb /dll /version:0.0 /machine:x64 /DEBUG /OPT:ICF /OPT:REF /INCREMENTAL:NO   && cd ."
> WebCore.lib(JSNodeDOMJIT.cpp.obj) : error LNK2005: "public: static class WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl WebCore::JSNode::checkSubClassPatchpoint(void)" (?checkSubClassPatchpoint@JSNode@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
> 
> WebCore.lib(JSDocumentDOMJIT.cpp.obj) : error LNK2005: "public: static class WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl WebCore::JSDocument::checkSubClassPatchpoint(void)" (?checkSubClassPatchpoint@JSDocument@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
> 
>    Creating library lib64\TestWebCoreLib.lib and object lib64\TestWebCoreLib.exp
Comment 1 Fujii Hironori 2017-05-18 03:13:11 PDT
WEBCORE_EXPORT is defined for dllexport in WebCore. This is strange becuase WebCore is a static library in Windows port.
Comment 2 Fujii Hironori 2017-05-18 03:43:21 PDT
This has happened since https://trac.webkit.org/changeset/217031
Comment 3 Yusuke Suzuki 2017-05-18 05:04:34 PDT
Hmmmm, it is very storange. These functions are only defined once in JSNodeDOMJIT.cpp & JSDocumentDOMJIT.cpp. And other ports just build it correctly.
Do you know the special things done for WebCore.lib & WebKit.lib in Windows?
Comment 4 Yusuke Suzuki 2017-05-18 05:20:18 PDT
(In reply to Yusuke Suzuki from comment #3)
> Hmmmm, it is very storange. These functions are only defined once in
> JSNodeDOMJIT.cpp & JSDocumentDOMJIT.cpp. And other ports just build it
> correctly.
> Do you know the special things done for WebCore.lib & WebKit.lib in Windows?

And I also note that JSEventDOMJIT.cpp, JSElementDOMJIT.cpp and JSDocumentFragmentDOMJIT.cpp also have similar `checkSubClassPatchpoint` functions. But they do not cause linker errors according to the log.
Comment 5 Fujii Hironori 2017-05-18 19:03:43 PDT
By checking with dumpbin, I've confirmed checkSubClassPatchpoint was exported from WebKit.dll.
I'm guessing a following simple scenario.

1) JSDocumentDOMJIT.cpp was compiled with dllexport in WebCore
2) The linker included JSDocumentDOMJIT.cpp.obj into WebKit.dll
3) The linker found some dllexport-marked symbols in JSDocumentDOMJIT.cpp.obj and exported them from WebKit.dll

I admit that this hypothesis doesn't explain comment 4.
Comment 6 Per Arne Vollan 2017-05-18 23:39:16 PDT
Perhaps we shouldn't link with both WebKit.lib and WebCore.lib? In theory, I guess TestWebCoreLib only needs to link with WebCore.lib, and TestWebKitLib only needs to link with WebKit.lib. I would expect to get many other linker errors if this was the case, though.
Comment 7 Yusuke Suzuki 2017-05-19 01:34:55 PDT
(In reply to Fujii Hironori from comment #5)
> By checking with dumpbin, I've confirmed checkSubClassPatchpoint was
> exported from WebKit.dll.
> I'm guessing a following simple scenario.
> 
> 1) JSDocumentDOMJIT.cpp was compiled with dllexport in WebCore
> 2) The linker included JSDocumentDOMJIT.cpp.obj into WebKit.dll
> 3) The linker found some dllexport-marked symbols in
> JSDocumentDOMJIT.cpp.obj and exported them from WebKit.dll
> 
> I admit that this hypothesis doesn't explain comment 4.

Right. I've just checked the generated JSNode.cpp in DerivedSoure.
And I've found that, whole JSNode class is annotated by WEBCORE_EXPORT,
while JSDocumentFragment is not.
Comment 8 Fujii Hironori 2017-05-19 01:50:16 PDT
Created attachment 310635 [details]
WIP patch

(In reply to Per Arne Vollan from comment #6)
> Perhaps we shouldn't link with both WebKit.lib and WebCore.lib? In theory, I
> guess TestWebCoreLib only needs to link with WebCore.lib, and TestWebKitLib
> only needs to link with WebKit.lib. I would expect to get many other linker
> errors if this was the case, though.

Sounds good!
Unfortunately, my WIP patch reports a following linkage error.

> ------ Build started: Project: TestWebCoreLib, Configuration: Debug x64 ------
>      Creating library C:/webkit/ga/WebKitBuild/Debug/lib64/TestWebCoreLib.lib and object C:/webkit/ga/WebKitBuild/Debug/lib64/TestWebCoreLib.exp
> WebCore.lib(ImageWin.obj) : error LNK2019: unresolved external symbol "class WTF::RefPtr<class WebCore::SharedBuffer> __cdecl loadResourceIntoBuffer(char const *)" (?loadResourceIntoBuffer@@YA?AV?$RefPtr@VSharedBuffer@WebCore@@@WTF@@PEBD@Z) referenced in function "public: static class WTF::Ref<class WebCore::Image> __cdecl WebCore::Image::loadPlatformResource(char const *)" (?loadPlatformResource@Image@WebCore@@SA?AV?$Ref@VImage@WebCore@@@WTF@@PEBD@Z)
> C:\webkit\ga\WebKitBuild\Debug\bin64\TestWebCoreLib.dll : fatal error LNK1120: 1 unresolved externals
> ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

There is a layer violation.
Comment 9 Per Arne Vollan 2017-05-19 01:59:04 PDT
(In reply to Fujii Hironori from comment #8)
> Created attachment 310635 [details]
> WIP patch
> 
> (In reply to Per Arne Vollan from comment #6)
> > Perhaps we shouldn't link with both WebKit.lib and WebCore.lib? In theory, I
> > guess TestWebCoreLib only needs to link with WebCore.lib, and TestWebKitLib
> > only needs to link with WebKit.lib. I would expect to get many other linker
> > errors if this was the case, though.
> 
> Sounds good!
> Unfortunately, my WIP patch reports a following linkage error.
> 
> > ------ Build started: Project: TestWebCoreLib, Configuration: Debug x64 ------
> >      Creating library C:/webkit/ga/WebKitBuild/Debug/lib64/TestWebCoreLib.lib and object C:/webkit/ga/WebKitBuild/Debug/lib64/TestWebCoreLib.exp
> > WebCore.lib(ImageWin.obj) : error LNK2019: unresolved external symbol "class WTF::RefPtr<class WebCore::SharedBuffer> __cdecl loadResourceIntoBuffer(char const *)" (?loadResourceIntoBuffer@@YA?AV?$RefPtr@VSharedBuffer@WebCore@@@WTF@@PEBD@Z) referenced in function "public: static class WTF::Ref<class WebCore::Image> __cdecl WebCore::Image::loadPlatformResource(char const *)" (?loadPlatformResource@Image@WebCore@@SA?AV?$Ref@VImage@WebCore@@@WTF@@PEBD@Z)
> > C:\webkit\ga\WebKitBuild\Debug\bin64\TestWebCoreLib.dll : fatal error LNK1120: 1 unresolved externals
> > ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
> 
> There is a layer violation.

Nice work! I suggest soft linking the loadResourceIntoBuffer function.
Comment 10 Yusuke Suzuki 2017-05-19 02:00:42 PDT
(In reply to Per Arne Vollan from comment #9)
> (In reply to Fujii Hironori from comment #8)
> > Created attachment 310635 [details]
> > WIP patch
> > 
> > (In reply to Per Arne Vollan from comment #6)
> > > Perhaps we shouldn't link with both WebKit.lib and WebCore.lib? In theory, I
> > > guess TestWebCoreLib only needs to link with WebCore.lib, and TestWebKitLib
> > > only needs to link with WebKit.lib. I would expect to get many other linker
> > > errors if this was the case, though.
> > 
> > Sounds good!
> > Unfortunately, my WIP patch reports a following linkage error.
> > 
> > > ------ Build started: Project: TestWebCoreLib, Configuration: Debug x64 ------
> > >      Creating library C:/webkit/ga/WebKitBuild/Debug/lib64/TestWebCoreLib.lib and object C:/webkit/ga/WebKitBuild/Debug/lib64/TestWebCoreLib.exp
> > > WebCore.lib(ImageWin.obj) : error LNK2019: unresolved external symbol "class WTF::RefPtr<class WebCore::SharedBuffer> __cdecl loadResourceIntoBuffer(char const *)" (?loadResourceIntoBuffer@@YA?AV?$RefPtr@VSharedBuffer@WebCore@@@WTF@@PEBD@Z) referenced in function "public: static class WTF::Ref<class WebCore::Image> __cdecl WebCore::Image::loadPlatformResource(char const *)" (?loadPlatformResource@Image@WebCore@@SA?AV?$Ref@VImage@WebCore@@@WTF@@PEBD@Z)
> > > C:\webkit\ga\WebKitBuild\Debug\bin64\TestWebCoreLib.dll : fatal error LNK1120: 1 unresolved externals
> > > ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
> > 
> > There is a layer violation.
> 
> Nice work! I suggest soft linking the loadResourceIntoBuffer function.

Yeah, that's great!
In the meantime, I'll land the original patch by extracting checkSubClassPatchpoint from JSNode / JSDocument and move it to WebCore::checkSubClassPatchpointFor{JSNode,JSDocument}.
Comment 11 Fujii Hironori 2017-05-19 02:47:10 PDT
Created attachment 310639 [details]
Patch

This is a layer violation and TestWebCore is just a unit test. I'd like to suggest to add a stub in TestWebCoreLib. How do you think this?
Comment 12 Per Arne Vollan 2017-05-19 07:03:50 PDT
(In reply to Fujii Hironori from comment #11)
> Created attachment 310639 [details]
> Patch
> 
> This is a layer violation and TestWebCore is just a unit test. I'd like to
> suggest to add a stub in TestWebCoreLib. How do you think this?

That sounds good! It seems the build problem on Win EWS is unrelated to this patch.
Comment 13 Fujii Hironori 2017-05-19 15:33:37 PDT
Win EWS gets green. Could anyone review this?
Comment 14 Per Arne Vollan 2017-05-19 23:27:00 PDT
Comment on attachment 310639 [details]
Patch

Looks good! R=me.
Comment 15 WebKit Commit Bot 2017-05-19 23:55:41 PDT
Comment on attachment 310639 [details]
Patch

Clearing flags on attachment: 310639

Committed r217184: <http://trac.webkit.org/changeset/217184>
Comment 16 WebKit Commit Bot 2017-05-19 23:55:43 PDT
All reviewed patches have been landed.  Closing bug.