|Version 35 (modified by 4 years ago) (diff),|
Setting up a Windows system for building GHC
Installing the following will get you a working build environment with MSYS. The instructions are current for GHC 7.6.
Other documentation for Windows includes:
- Using Cygwin to build GHC. Using MSYS is the preferred approach though.
- MinGW/MSYS/Cgwin information for people new to using UNIX tools on Windows.
- Using SSH on Windows.
Setting up Windows
- Install the following tools:
We recommend using the default install locations for all these tools. If you choose your own paths, then we recommend not using a path containing spaces if the default did not have spaces.
- Install the MinGW and MSYS tools:
MinGW provides a windows version of GCC while MSYS provides a minimal UNIX environment (e.g bash, make... ect). The website for MinGW is totally confusing, so go here Mingw/MSYS Getting Started and follow the download instructions for the mingw-get-inst installer. This is an easy to use installer for installing both MinGW and MSYS. Make sure when you run the installer that you select to install g++, MSYS and the MSYS Dev Kit.
- Set your
PATH. You need to include at least
c:/git/bin(or wherever you installed git)
c:/Python27(or wherever you installed Python)
c:/dev/llvm/bin(or wherever you installed LLVM, if you got it)
- The Haskell platform installer should have already done the work needed to make GHC,
alexavailable on the path, but if not add them too:
Moreover, these must precede the standard
c:/windows/system32: see below for the Awful Warnings about your PATH.
We recommend doing this by creating a file
.profilein your home directory (by default
c:/MinGW/msys/1.0/home/<username>). The contents of your
.profileshould be something like this:# Add Python to path export PATH=/c/Python27:$PATH ...etc..etc...
- If you use a shell within Emacs, make sure your
SHELLenvironment variable points to the
- Launch the shell by starting the 'MinGW Shell' which should be in your start menu.
autoconf --versionto check that you have at least version 2.68 of
autoconf. Version 2.56 (which was around for a long time) does not work for GHC's build system.
You should now have a working environment for getting the source for GHC and building it!
Disable realtime virus-scanning for your build
Realtime virus scanners are prone to causing weird build failures, typically "permission denied" errors that go away when the build is restarted. The best way to avoid these problems is to exclude the directory containing your GHC build from realtime virus scanning, if your scanner supports excluding particular directories. You probably also want to exclude directories in which temporary files are stored, which by default is
C:/Users/<user>/Local Settings/Temp on Windows Vista and later,
C:/Documents and Settings/<user>/Local Settings/Temp on Windows XP and older, or
Building documentation on Windows
Building GHC's documentation is optional, but in order to build it in Windows you must currently use Cygwin (there isn't a working DocBook toolchain on MSYS as far as we know).
In the Cygwin installer, just install the complete
Doc category. You may have to help
configure a little bit: Set the environment variables
XsltprocCmd to the paths of the Cygwin executables
xsltproc, respectively, and set
fp_cv_dir_docbook_xsl to the path of the directory where the XSL stylesheets are installed, e.g.
If you want to build HTML Help, you have to install the HTML Help SDK, tool, and make sure that
hhc is in your
Awful warnings about your PATH
It is very important to put the msys/mingw stuff on your path before
c:/windows/system32. Here is what happens if you don't.
sh libtool hangs indefinitely. The process manager shows an extant
sed, but nothing else.
libtool is a shell script that comes from a tarball, and is unpacked into
libtool invokes the following command line (in the function
cmd /c “echo blah”
and pipes the result to
sed. But MSYS mangles the command line to turn slashes into backslashes. So the actual command line is more like
cmd \c “echo blah”
which does something entirely different, and indeed hangs waiting for input on stdin.
Solution: How did this ever work on any MSYS installation? Because
msys/1.0/binhas a little script “cmd” which hands off to the real c:/windows/system32/cmd
- MSYS does not mangle the command-line for programs in
- On my old laptop,
msys/1.0/binwas in my path before
c:/windows/system32. So plain
cmdgets the script, and MSYS does not mangle the command line. The script passes arguments on unchanged to the real cmd.
c:/windows/system32is in the “system” path, which precedes the “user” path. So no amount of fiddling with the “user” path will fix this. There are two solutions:
- Modify the system path
- Use a .bashrc file to prepend the stuff you need