Building GHC on Windows
This guide should get you running in ~5 minutes, modulo download speeds.
Download and run the 64-bit MSYS2 installer. Be sure to open a mingw64 shell (see below).
Download and run the 32-bit MSYS2 installer. Be sure to open a mingw32 shell (see below).
The result of attempting to create a 32-bit build on a 64-bit machine has not been documented yet. Building on a 32-bit version of Windows works, of course.
From the MSYS2 installation instructions:
After installing or extracting MSYS2 you should start MSYS2 by executing msys2_shell.bat.
(if you did not use an installer and this is first time running of MSYS2 after unpacking, then at this point it will create the files and settings necessary for it to function properly. After this initial run you MUST restart MSYS2 so that the settings are correct)
Configuring MinGW properly
IMPORTANT: The MSYS2 installer creates multiple shortcuts, "MSYS2 Shell", "MinGW-w64 Win32 Shell" and "MinGW-w64 Win64 Shell". You do not want the "MSYS2 Shell." The MSYS2 shell is set up for building applications with Cygwin which provides an additional POSIX compatibility layer, while MinGW is set up for building native Windows applications which is what we need for GHC.
An easy way to check that you are running the right shell is to check the output of echo $MSYSTEM. It should show either MINGW32 or MINGW64. You can also tell by examining the $PATH.
*NOTE:* if after installing packages like Sphinx ./configure still reports it is missing, make sure /mingw64/bin (or /mingw32/bin depending on the arch you're building for) is on the $PATH
Installing packages & tools
The msys2 package uses pacman (the venerable ArchLinux package manager) to manage packages. Before installing system dependencies required for building GHC, first let's update pacman. Modern msys2 versions include an update-core script and the preferred way of updating msys2 is as follows (from MSYS2 installation instructions Section III which also includes update instructions for old versions of msys2):
Run update-core. If one of the packages is updated during script run you MUST restart MSYS2
Run pacman -Su
Because msys2 programs all share the same address space for DLLs, updating bash, pacman, or msys2 itself may cause errors without restarting the shell. Running update-core avoids this by first syncing the local package databases with the latest repositories (pacman -Sy), then updating the core msys2 packages. Then, you can update the rest of the packages with pacman -Su. The -S (short for --sync) indicates that you wish to install the given packages. -u (short for --sysupgrade) indicates that you want to upgrade existing packages.
Now we can install GHC's system dependencies as followed:
pacman -S --needed git tar binutils autoconf make \ curl libtool automake python python2 p7zip patch \ mingw-w64-$(uname -m)-gcc mingw-w64-$(uname -m)-python3-sphinx
If this pacman process fails (as it sometimes does) you can simply re-run it as it ought to be idempotent.
The 64-bit MinGW-w64 version of curl is known to fail (see this issue) when used with the mk/get-win32-tarballs.sh script:
$ mk/get-win32-tarballs.sh download x86_64 Downloading mingw-w64-x86_64-crt-git-220.127.116.1131.49c7046-1-any.pkg.tar.xz to ghc-tarballs/mingw-w64/x86_64... Warning: Failed to create the file Warning: ghc-tarballs/mingw-w64/x86_64/mingw-w64-x86_64-crt-git-18.104.22.16831.49c7 Warning: 046-1-any.pkg.tar.xz: No such file or directory curl: (23) Failed writing body (0 != 2759) ERROR: Download failed.
To see if you are have the 64-bit MinGW-w64 version of curl installed, check if the beginning of the output of curl --version is
curl <version-number> (x86_64-w64-mingw32)
If it doesn't (e.g., curl <version-number> (x86_64-pc-msys) corresponds to the MSYS2 curl), you have nothing to worry about. If it does, you have some options:
- You can alias the MSYS2 version of curl by adding the line:
to your ~/.bashrc file.
- You can temporarily uninstall the 64-bit MinGW-w64 version of curl with pacman -R mingw-w64-x86_64-curl before building GHC. (You can then reinstall it later with pacman -S mingw-w64-x86_64-curl.)
- If you really want to use the 64-bit MinGW-w64 version of curl to install GHC, you can with a little extra effort. As a workaround, you can run:
mkdir -p ghc-tarballs/mingw-w64/x86_64 mkdir -p ghc-tarballs/perl
before running mk/get-win32-tarballs.sh download x86_64.
Host GHC setup
A host GHC binary is required for bootstrapping. In order to keep different architectures separate, download and install a prebuilt GHC into /mingw64 or /mingw32:
So for 64-bit you'd run
curl -L https://www.haskell.org/ghc/dist/7.10.3/ghc-7.10.3-x86_64-unknown-mingw32.tar.xz | tar -xJ -C /mingw64 --strip-components=1
and for 32-bit you'd run
curl -L https://www.haskell.org/ghc/dist/7.10.3/ghc-7.10.3-i386-unknown-mingw32.tar.xz | tar -xJ -C /mingw32 --strip-components=1
Note: --strip-components=1 places everything within the archive's ghc-7.10.1 folder directly into the target directory.
mkdir -p /usr/local/bin && curl -L https://www.haskell.org/cabal/release/cabal-install-22.214.171.124/cabal-126.96.36.199-i386-unknown-mingw32.tar.gz | tar -xz -C /usr/local/bin && mv /usr/local/bin/cabal-188.8.131.52-i386-unknown-mingw32.exe /usr/local/bin/cabal.exe && cabal update && cabal install -j --prefix=/usr/local alex happy
Note for Windows Server 2008 R2 users
The pre-packaged cabal-184.108.40.206 crashes on Windows Server 2008 R2 during cabal update due to this bug. If so, try using a different version such as:
mkdir -p /usr/local/bin && curl -LO https://www.haskell.org/cabal/release/cabal-install-220.127.116.11-rc1/cabal-install-18.104.22.168-rc1-x86_64-unknown-mingw32.zip && unzip cabal-install-22.214.171.124-rc1-x86_64-unknown-mingw32.zip -d /usr/local/bin && cabal update && cabal install -j --prefix=/usr/local alex happy
A Quick Build
You should now be able to build GHC:
# Clone to ./ghc git clone --recursive git://git.haskell.org/ghc.git && cd ghc
Consider setting up mk/build.mk here (cp mk/build.mk.sample mk/build.mk && vim mk/build.mk).
Finally, to perform the actual build:
./boot && ./configure --enable-tarballs-autodownload && make
Running parallel make (e.g., make -j5) is faster, but appears to cause segfaults during the build sometimes. The reasons are not clear yet.
MSYS2 is known to be glitchy in some situations. If you see errors related to fork(), try closing and reopening the shell; see also msys2 issue #74. Also there have been issues with the build process segfaulting. The reason is not known (we're looking into it). If that happens, simply rerunning make will continue the build process.
Alternatively, to run a pristine build and tests (takes a while):
NOTE: You may see an error like make 7628 child_info_fork::abort: ... make: fork: Resource temporarily unavailable when running make. To fix this, go to the root of your MSYS dir and run autorebase.bat; see http://sourceforge.net/projects/mingw/files/MSYS/Extension/rebase/rebase-4.0.1_1-1/ and again http://sourceforge.net/p/msys2/tickets/74/. Alternatively, run shutdown //r.
NOTE: If the build seems super slow (takes more than 1 hour to complete), check your virus scanner and whitelist C:/msys64.
Other documentation for Windows includes:
- MinGW/MSYS/Cygwin information for people new to using UNIX tools on Windows.
- Setting up a SSH Daemon on CygWin/MinGW and let's you treat Windows as yet another remote SSH session.
- Using MSYS1 to build GHC (not recommended any more)
- Using Cygwin to build GHC. (no longer supported)
- Using SSH on Windows.
- Guidance on how to use Haskell on Windows