Bug 193899 – webkit wincairo port build failed on MSVC

• Component: CMake
• Status: RESOLVED FIXED

[QuellaZhang]

Created attachment 360329 [details]
build log

Hi all,

The MSVC team builds WebKit regularly to detect regressions, recentlly we want to build wincairo port, but there are some issues, we always use the latest source from master, could you help look at this? I have attahced the build log.

Repro steps:
1. git clone https://github.com/WebKit/webkit d:\WebKit\src
2. open a VS 2017 x64 command prompt as admin and browse to D:\Webkit
3. extra WebKitLibrary\win to D:\WebKit\src\WebKitLibraries\win
4. set path=C:\gnuwin32\bin;%path%
6. cmake -DPORT="WinCairo" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 15 2017 Win64" -DCMAKE_GENERATOR_TOOLSET="host=x64" -DSHOW_BINDINGS_GENERATION_PROGRESS=1 -DDEVELOPER_MODE=ON -DENABLE_EXPERIMENTAL_FEATURES=ON -DCMAKE_SYSTEM_VERSION=10.0.17134.0 -DRUBY_LIBRARY=C:\Ruby25-x64\lib D:\webkit\src
7. msbuild /p:Configuration=Release;Platform=x64 WebKit.sln /t:Rebuild

Failures(see attachment):
D:\WebKit\build_x64\DerivedSources\ForwardingHeaders\WebCore\Process.h(32,28): error C2011:  'WebCore::ProcessIdentifierType': 'enum' type redefinition [D:\WebKit\build_x64\Source\WebKit\WebKit.vcxproj]
D:\WebKit\build_x64\DerivedSources\ForwardingHeaders\WebCore\Process.h(32,28): error C2011: enum ProcessIdentifierType { }; [D:\WebKit\build_x64\Source\WebKit\WebKit.vcxproj]
D:\WebKit\build_x64\DerivedSources\ForwardingHeaders\WebCore\Process.h(32,28): error C2011:                            ^ (compiling source file D:\WebKit\src\Source\WebKit\UIProcess\DefaultUndoController.cpp) [D:\WebKit\build_x64\Source\WebKit\WebKit.vcxproj]
  WebPopupMenuProxyWin.cpp
D:\WebKit\build_x64\DerivedSources\ForwardingHeaders\WebCore\Process.h(32,28): error C2011:  'WebCore::ProcessIdentifierType': 'enum' type redefinition [D:\WebKit\build_x64\Source\WebKit\WebKit.vcxproj]
D:\WebKit\build_x64\DerivedSources\ForwardingHeaders\WebCore\Process.h(32,28): error C2011: enum ProcessIdentifierType { }; [D:\WebKit\build_x64\Source\WebKit\WebKit.vcxproj]
D:\WebKit\build_x64\DerivedSources\ForwardingHeaders\WebCore\Process.h(32,28): error C2011:                            ^ (compiling source file D:\WebKit\src\Source\WebKit\UIProcess\win\PageClientImpl.cpp) [D:\WebKit\build_x64\Source\WebKit\WebKit.vcxproj]
  DrawingAreaImpl.cpp

  WebCore.lib(PNGImageDecoder.obj) : error LNK2019: unresolved external symbol png_save_uint_32 referenced in function "public: void __cdecl WebCore::PNGImageDecoder::headerAvailable(void)" (?headerAvailable@PNGImageDecoder@WebCore@@QEAAXXZ) [D:\WebKit\build_x64\Tools\TestWebKitAPI\TestWebCoreLib.vcxproj]
  WebCore.lib(PNGImageDecoder.obj) : error LNK2019: unresolved external symbol png_save_uint_16 referenced in function "public: void __cdecl WebCore::PNGImageDecoder::headerAvailable(void)" (?headerAvailable@PNGImageDecoder@WebCore@@QEAAXXZ) [D:\WebKit\build_x64\Tools\TestWebKitAPI\TestWebCoreLib.vcxproj]
  D:\WebKit\build_x64\bin64\TestWebCoreLib.dll : fatal error LNK1120: 34 unresolved externals [D:\WebKit\build_x64\Tools\TestWebKitAPI\TestWebCoreLib.vcxproj]

[Fujii Hironori]

Thank you very much for taking WinCairo port into account.

Why don't you use build-webkit script? WinCairo BuildBot is using it. 

https://build.webkit.org/builders/WinCairo%2064-bit%20WKL%20Release%20%28Build%29

> perl ./Tools/Scripts/build-webkit --release --wincairo

It seems you have a wrong libpng, but your log is missing the important part, for example like follwoing log of CMake configure.

https://build.webkit.org/builders/WinCairo%2064-bit%20WKL%20Debug%20%28Build%29/builds/5926/steps/compile-webkit/logs/stdio

> -- Found PNG: C:/WebKit-BuildWorker/wincairo-wkl-debug/build/WebKitLibraries/win/lib64/libpng16.lib (found suitable version "1.6.35", minimum required is "1.6.34")

[Fujii Hironori]

JFYI, I documented WinCairo build instruction here.
https://trac.webkit.org/wiki/BuildingCairoOnWindows

[Don Olmstead]

Awhile back Phil Christensen was doing some bug hunting on MSVC + WebKit and process.h causing issues was something that he hit.

> In our compiler development branch there is a recent change so <thread> will now include <process.h> from our CRT.  Unfortunately the WebKit build finds a file of the same name under WebCore\platform instead of from the CRT.  The reason we were first suspicious of the #pragma compiler change is because the same translation can also include the copy of process.h that is part of the forwarding headers which causes confusing redefinition errors.

> The change to <thread> that triggered this issue will be part of the compiler 16.0 release, so you will have some time to address it before it is released.  Depending on your build it may be as simple as swapping the order of the include paths.  If all the appropriate headers are copied under the forwarding headers, then maybe WebCore\platform can be removed from the include path altogether.  Although in big projects changes like this are rarely that simple.  If you are able to resolve your metabug 180064 then it would probably also address this issue.

I think first thing should be renaming platform/Process.h to platform/ProcessIdentifier.h just in case this is your issue.

[Fujii Hironori]

Thanks, Don. Filed: Bug 193944 – [Win] WebCore/platform/Process.h is conflicting with process.h

[Don Olmstead]

QuellaZang did that by chance fix your issue? The patch renaming the Process.h file was landed.

[QuellaZhang]

Thank you very much, now we have got a clean x64-build on wincairo port with latest webkit version 40ba953.

In fact, I first used the official build command(perl build-webkit --wincairo), but I got the below error, we want to use MSVC, but it finds gcc or clang, do you have any solution? Thanks in advance.

>perl ./Tools/Scripts/build-webkit --release --wincairo
Updating WinCairoRequirements.zip...
Found existing release: v2018.11.27
Seeking latest release from WebKitForWindows/WinCairoRequirements...
Found release to download: v2018.11.27
Already up-to-date!
Updating vswhere.exe...
No existing release found.
Seeking latest release from Microsoft/vswhere...
Found release to download: 2.5.9
Downloading to D:\WebKit\src\WebKitLibraries\win\tools...
Done!
+  cmake -DPORT="WinCairo" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=Release -G Ninja -DDEVELOPER_MODE=ON -DENABLE_EXPERIMENTAL_FEATURES=ON "D:/WebKit/src"
-- The C compiler identification is GNU 5.2.0
-- The CXX compiler identification is GNU 5.2.0
-- Check for working C compiler: C:/Program Files/Haskell Platform/8.0.2-a/mingw/bin/gcc.exe
-- Check for working C compiler: C:/Program Files/Haskell Platform/8.0.2-a/mingw/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/Program Files/Haskell Platform/8.0.2-a/mingw/bin/c++.exe
-- Check for working CXX compiler: C:/Program Files/Haskell Platform/8.0.2-a/mingw/bin/c++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The CMake build type is: Release
CMake Error at CMakeLists.txt:65 (message):
  GCC 6.0.0 is required to build WebKitGTK+, use a newer GCC version or clang


-- Configuring incomplete, errors occurred!
See also "D:/WebKit/src/WebKitBuild/Release/CMakeFiles/CMakeOutput.log".
Run Visual Studio 2017 installation vcvars.bat before build-webkit when using ninja at ./Tools/Scripts/build-webkit line 304.

[Fujii Hironori]

Oh, that's right. CMake chooses GCC if it's found in your PATH.
You need to modify your PATH not to include GCC before invoking build-webkit.

build-webkit is going to use CMake Ninja generator instead of CMake VS generator if ninja.exe is found in your PATH.
Use --no-ninja switch or modify you PATH.
> perl ./Tools/Scripts/build-webkit --release --wincairo --no-ninja

[Fujii Hironori]

Revised the doc: https://trac.webkit.org/wiki/BuildingCairoOnWindows
Please reopen, or file a new ticket if you have more issues.