|Version 38 (modified by firstname.lastname@example.org, 3 years ago) (diff)|
Building on Windows
- Building from within Visual Studio
- Common Build Errors
- Other Common Errors
- Running the Layout Tests on Windows
See ImprovingLifeOnWindows for ideas about how to make developing WebKit on Windows easier.
Building on Windows
Follow the instructions on http://webkit.org/building/tools.html to install the necessary developer tools, support libraries, and check out the WebKit code.
Note that it is safest to build WebKit in your Cygwin home directory. At the moment, there seems to be an implicit assumption in the build scripts that paths will be relative to the home directory.
Building from within Visual Studio
WebKit can be built from within Visual Studio by setting two environment variables:
- WEBKITOUTPUTDIR - An absolute Windows-style path pointing to the directory where you want the build products to go.
- WEBKITLIBRARIESDIR - An absolute Windows-style path pointing to the WebKitLibraries/win folder in your WebKit checkout.
Common Build Errors
Error spawning cmd.exe / Linker errors
Sometimes, Visual Studio complains that it 'cannot spawn cmd.exe'. Should this happen, check if both your Cygwin\bin folder and c:\windows\sytem32 are in the Visual Studio list of executable files (Tools -> Options -> VC++ Directories) and that your Cygwin\bin appears after the Visual Studio bin folders (Otherwise, the wrong link.exe will be used; that is, the Cygwin link.exe will be used instead of the Visual Studio tool of the same name).
Missing Autogenerated Files
If you have the Visual Studio IDE open while you are performing an update-webkit, you can sometimes run into a strange problem where Visual Studio is unable to locate the autogenerated files. These files are usually things like HTMLNames.cpp, which are generated by Perl as part of the WebCoreGenerated target.
Bad line endings
When you see errors in WebCore/css/makeprops or WebCore/css/maketokenizer, open those files in a suitable editor (SciTE works) and convert the line endings to LF only (Unix-style). Then restart the build.
Visual Studio 2005
Early versions of Visual Studio 2005 are missing the library 'Crypt32.lib'. A workaround is to download and install the Windows Server 2003 R2 Platform SDK then copy the file 'Crypt32.lib' from the directory C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Lib to %VSINSTALLDIR%\VC\PlatformSDK\Lib.
Visual C++ Express Edition
If you see errors like this you probably need to install the platform SDK.
Project : error PRJ0002 : Error result -1073741515 returned from 'c:\Program Files\Microsoft Visual Studio 8\VC\bin\cl.exe'
If you see this error and/or when you manually execute c:\Program Files\Microsoft Visual Studio 8\VC\bin\cl.exe you see the error message "This application has failed to start because mspdb80.dll was not found. Re-installing the application may fix this problem" then you need to ensure that the directory C:\Program Files\Microsoft Visual Studio 8\Common7\IDE is listed in the PATH environment variable.
If you see errors opening the WebKit solution in Visual Studio/Visual C++ Express that say:
"$(WebKitLibrariesDir)/tools/vsprops/common.vsprops could not be found or failed to load"
(or some other .vsprops file), you must set the "WebKitLibrariesDir" environment variable. Make sure that "WebKitLibrariesDir" points to the "WebKitLibraries/win" directory, not the "WebKitLibraries/" directory.
Missing packages in Cygwin
You may have had cygwin already installed before attempting to build WebKit. In this case, you should have checked your cygwin setup to make sure that you have at least the following packages installed: bison, gawk, flex, gperf, perl, zlib. The error reports you get when you miss one such package are particularly cryptic and may not lead you to those packages.
If you'd rather reconcile each package and version manually, rather than use the cygwin installer, you may find the list of packages included in the cygwin installer useful.
Other Common Errors
Perl warnings when you run run-webkit-tests
If you see Perl warnings when you run run-webkit-tests of the form:
readline() on closed filehandle INSTALL_DIR at /home/Administrator/WebKitTools/Scripts/webkitdirs.pm line 1536. Use of uninitialized value $path in substitution (s///) at /home/Administrator/WebKitTools/Scripts/webkitdirs.pm line 1537. Use of uninitialized value $path in concatenation (.) or string at /home/Administrator/WebKitTools/Scripts/webkitdirs.pm line 1540.
then you must install Safari 4.0.4 or greater.
Error launching Apache from run-webkit-tests on Vista
You need to rebase libphp4.dll. Run the following command:
/bin/rebase -d -b 0x70000000 -o 0x10000 WebKit/LayoutTests/http/conf/libphp4.dll
Debugging information cannot be found
When following the instructions on http://webkit.org/building/debug.html on how to debug WebKit on Windows, Visual Studio displays the message:
"Debugging information for 'Safari.exe' cannot be found or does not match. No symbols loaded."
If not, check that you followed the instructions on how to configure Visual Studio to use Apple's Safari for Windows symbol server on the bottom of http://webkit.org/building/debug.html.
Running the Layout Tests on Windows
Running the layout-tests without failures requires a few tweaks to the environment:
Running layout-test on Windows requires a set of fonts not normally bundled with Windows. The full list of required fonts can be found here:
Most of these fonts come from OS X, so they can't be freely redistributed as one font-package for testing-purposes.
They can however be copied from your Mac (if you have one), but they have to be converted into a TrueType format Windows understands.
- *.ttc files can be extraced using a tool from http://www.xlsoft.com/jp/products/indigorose/files/ttsdk.zip
- *.dfont and Mac-style *.ttf files can be converted using CrossFont (the trial edition works fine).
Look in /System/Library/Fonts and /Library/Fonts for the source files.
The rest of the fonts can be found here:
The easiest approach is to convert all these fonts to Windows-style TrueType fonts and put them in a single folder. Then point the WEBKIT_TESTFONTS environment variable to that directory when running run-webkit-tests.
Note however that you might still see metric-related failures (if anyone knows why, please update this section with more complete instructions).