12. Notes for building under Windows

This section summarises how to get the utilities you need on your Win95/98/NT/2000 machine to use CVS and build GHC. Similar notes for installing and running GHC may be found in the user guide. In general, Win95/Win98 behave the same, and WinNT/Win2k behave the same. You should read the GHC installation guide sections on Windows (in the user guide) before continuing to read these notes.

12.1. Cygwin and MinGW

The Windows situation for building GHC is rather confusing. This section tries to clarify, and to establish terminology.

12.1.1. GHC-mingw

MinGW (Minimalist GNU for Windows) is a collection of header files and import libraries that allow one to use gcc and produce native Win32 programs that do not rely on any third-party DLLs. The current set of tools include GNU Compiler Collection (gcc), GNU Binary Utilities (Binutils), GNU debugger (Gdb), GNU make, and a assorted other utilities.

The GHC that we distribute includes, inside the distribution itself, the MinGW gcc, as, ld, and a bunch of input/output libraries. GHC compiles Haskell to C (or to assembly code), and then invokes these MinGW tools to generate an executable binary. The resulting binaries can run on any Win32 system.

We will call a GHC that targets MinGW in this way GHC-mingw.

The down-side of GHC-mingw is that the MinGW libraries do not support anything like the full Posix interface. So programs compiled with GHC-mingw cannot import the (Haskell) Posix library; they have to do their input output using standard Haskell I/O libraries, or native Win32 bindings.

12.1.2. GHC-cygwin

There is a way to get the full Posix interface, which is to use Cygwin. Cygwin is a complete Unix simulation that runs on Win32. Cygwin comes with a shell, and all the usual Unix commands: mv, rm, ls, plus of course gcc, ld and so on. A C program compiled with the Cygwin gcc certainly can use all of Posix.

So why doesn't GHC use the Cygwin gcc and libraries? Because Cygwin comes with a DLL that must be linked with every runnable Cygwin-compiled program. A program compiled by the Cygwin tools cannot run at all unless Cygwin is installed. If GHC targeted Cygwin, users would have to install Cygwin just to run the Haskell programs that GHC compiled; and the Cygwin DLL would have to be in the DLL load path. Worse, Cygwin is a moving target. The name of the main DLL, cygwin1.dll does not change, but the implementation certainly does. Even the interfaces to functions it exports seem to change occasionally. So programs compiled by GHC might only run with particular versions of Cygwin. All of this seems very undesirable.

Nevertheless, it is certainly possible to build a version of GHC that targets Cygwin; we will call that GHC-cygwin. The up-side of GHC-cygwin is that Haskell programs compiled by GHC-cygwin can import the (Haskell) Posix library.

12.1.3. HOST_OS vs TARGET_OS

In the source code you'll find various ifdefs looking like:
  #ifdef mingw32_HOST_OS
    ...blah blah...
  #ifdef mingw32_TARGET_OS
    ...blah blah...
These macros are set by the configure script (via the file config.h). Which is which? The criterion is this. In the ifdefs in GHC's source code:

  • The "host" system is the one on which GHC itself will be run.

  • The "target" system is the one for which the program compiled by GHC will be run.

For a stage-2 compiler, in which GHCi is available, the "host" and "target" systems must be the same. So then it doesn't really matter whether you use the HOST_OS or TARGET_OS cpp macros.

12.1.4. Summary

Notice that "GHC-mingw" means "GHC that targets MinGW". It says nothing about how that GHC was built. It is entirely possible to have a GHC-mingw that was built by compiling GHC's Haskell sources with a GHC-cygwin, or vice versa.

We distribute only a GHC-mingw built by a GHC-mingw; supporting GHC-cygwin too is beyond our resources. The GHC we distribute therefore does not require Cygwin to run, nor do the programs it compiles require Cygwin.

The instructions that follow describe how to build GHC-mingw. It is possible to build GHC-cygwin, but it's not a supported route, and the build system might be flaky.

In your build tree, you build a compiler called ghc-inplace. It uses the gcc that you specify using the --with-gcc flag when you run configure (see below). The makefiles are careful to use ghc-inplace (not gcc) to compile any C files, so that it will in turn invoke the right gcc rather that whatever one happens to be in your path. However, the makefiles do use whatever ld and ar happen to be in your path. This is a bit naughty, but (a) they are only used to glom together .o files into a bigger .o file, or a .a file, so they don't ever get libraries (which would be bogus; they might be the wrong libraries), and (b) Cygwin and Mingw use the same .o file format. So its ok.

12.2. Installing and configuring Cygwin

You don't need Cygwin to use GHC, but you do need it to build GHC.

Install Cygwin from http://www.cygwin.com/. The installation process is straightforward; we install it in c:/cygwin. During the installation dialogue, make sure that you select: cvs, openssh, autoconf, binutils (includes ld and (I think) ar), gcc, flex, make.

Now set the following user environment variables:

There are a few other things to do:

Finally, here are some things to be aware of when using Cygwin:

12.3. Configuring SSH

ssh comes with Cygwin, provided you remember to ask for it when you install Cygwin. (If not, the installer lets you update easily.) Look for openssh (not ssh) in the Cygwin list of applications!

There are several strange things about ssh on Windows that you need to know.

12.4. Other things you need to install

You have to install the following other things to build GHC:

12.5. Building GHC

OK! Now go read the documentation above on building from source (Section 7); the bullets below only tell you about Windows-specific wrinkles.