|Building the Glasgow Functional Programming Tools Suite|
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.
The Windows situation for building GHC is rather confusing. This section tries to clarify, and to establish terminology.
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.
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.
In the source code you'll find various ifdefs looking like:
#ifdef mingw32_HOST_OS ...blah blah... #endif
#ifdef mingw32_TARGET_OS ...blah blah... #endif
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.
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.
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:
Add c:/cygwin/bin and c:/cygwin/usr/bin to your PATH
Set MAKE_MODE to UNIX. If you don't do this you get very weird messages when you type make, such as:
/c: /c: No such file or directory
Set SHELL to c:/cygwin/bin/sh. When you invoke a shell in Emacs, this SHELL is what you get.
Set HOME to point to your home directory. This is where, for example, bash will look for your .bashrc file. Ditto emacs looking for .emacsrc
There are a few other things to do:
By default, cygwin provides the command shell ash as sh.exe. We have often seen build-system problems that turn out to be due to bugs in ash (to do with quoting and length of command lines). On the other hand bash seems to be rock solid. So, in cygwin/bin remove the supplied sh.exe (or rename it as ash.exe), and copy bash.exe to sh.exe. You'll need to do this in Windows Explorer or the Windows cmd shell, because you can't rename a running program!
Some script files used in the make system start with "#!/bin/perl", (and similarly for sh). Notice the hardwired path! So you need to ensure that your /bin directory has the following binaries in it:
Finally, here are some things to be aware of when using Cygwin:
Cygwin doesn't deal well with filenames that include spaces. "Program Files" and "Local files" are common gotchas.
Cygwin implements a symbolic link as a text file with some magical text in it. So other programs that don't use Cygwin's I/O libraries won't recognise such files as symlinks. In particular, programs compiled by GHC are meant to be runnable without having Cygwin, so they don't use the Cygwin library, so they don't recognise symlinks.
Win32 has a find command which is not the same as Cygwin's find. You will probably discover that the Win32 find appears in your PATH before the Cygwin one, because it's in the system PATH environment variable, whereas you have probably modified the user PATH variable. You can always invoke find with an absolute path, or rename it.
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.
The programs ssh-keygen1, ssh1, and cvs, seem to lock up bash entirely if they try to get user input (e.g. if they ask for a password). To solve this, start up cmd.exe and run it as follows:
c:\tmp> set CYGWIN32=tty c:\tmp> c:/user/local/bin/ssh-keygen1
ssh needs to access your directory .ssh, in your home directory. To determine your home directory ssh first looks in c:/cygwin/etc/passwd (or wherever you have Cygwin installed). If there's an entry there with your userid, it'll use that entry to determine your home directory, ignoring the setting of the environment variable $HOME. If the home directory is bogus, ssh fails horribly. The best way to see what is going on is to say
ssh -v cvs.haskell.org
You can fix this problem, either by correcting the home-directory field in c:/cygwin/etc/passwd, or by simply deleting the entire entry for your userid. If you do that, ssh uses the $HOME environment variable instead.
To protect your .ssh from access by anyone else, right-click your .ssh directory, and select Properties. If you are not on the access control list, add yourself, and give yourself full permissions (the second panel). Remove everyone else from the access control list. Don't leave them there but deny them access, because 'they' may be a list that includes you!
In fact ssh 3.6.1 now seems to require you to have Unix permissions 600 (read/write for owner only) on the .ssh/identity file, else it bombs out. For your local C drive, it seems that chmod 600 identity works, but on Windows NT/XP, it doesn't work on a network drive (exact dteails obscure). The solution seems to be to set the $CYGWIN environment variable to "ntsec neta". The $CYGWIN environment variable is discussed in the Cygwin User's Guide, and there are more details in the Cygwin FAQ.
You have to install the following other things to build GHC:
Install an executable GHC, from http://www.haskell.org/ghc. This is what you will use to compile GHC. Add it in your PATH: the installer tells you the path element you need to add upon completion.
Install an executable Happy, from http://www.haskell.org/happy. Happy is a parser generator used to compile the Haskell grammar. Add it in your PATH.
Install Alex. This can be done by building from the source distribution in the usual way. Sources are available from http://www.haskell.org/alex.
Do not add any of the mingw binaries to your path. They are only going to get used by explicit access (via the --with-gcc flag you give to configure later). If you do add them to your path you are likely to get into a mess because their names overlap with Cygwin binaries.
We use emacs a lot, so we install that too. When you are in fptools/ghc/compiler, you can use "make tags" to make a TAGS file for emacs. That uses the utility fptools/ghc/utils/hasktags/hasktags, so you need to make that first. The most convenient way to do this is by going make boot in fptools/ghc. The make tags command also uses etags, which comes with emacs, so you will need to add emacs/bin to your PATH.
Finally, check out a copy of GHC sources from the CVS repository, following the instructions above (Section 2.1).
OK! Now go read the documentation above on building from source (Section 7); the bullets below only tell you about Windows-specific wrinkles.
Run autoconf both in fptools and in fptools/ghc. If you omit the latter step you'll get an error when you run ./configure:
...lots of stuff... creating mk/config.h mk/config.h is unchanged configuring in ghc running /bin/sh ./configure --cache-file=.././config.cache --srcdir=. ./configure: ./configure: No such file or directory configure: error: ./configure failed for ghc
autoconf seems to create the file configure read-only. So if you need to run autoconf again (which I sometimes do for safety's sake), you get
/usr/bin/autoconf: cannot create configure: permission denied
You either need to add ghc to your PATH before you invoke configure, or use the configure option --with-ghc=c:/ghc/ghc-some-version/bin/ghc.
If you are paranoid, delete config.cache if it exists. This file occasionally remembers out-of-date configuration information, which can be really confusing.
After autoconf run ./configure in fptools/ thus:
./configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc
Both these options are important! It's possible to get into trouble using the wrong C compiler!
Furthermore, it's very important that you specify a full MinGW path for gcc, not a Cygwin path, because GHC (which uses this path to invoke gcc) is a MinGW program and won't understand a Cygwin path. For example, if you say --with-gcc=/mingw/bin/gcc, it'll be interpreted as /cygdrive/c/mingw/bin/gcc, and GHC will fail the first time it tries to invoke it. Worse, the failure comes with no error message whatsoever. GHC simply fails silently when first invoked, typically leaving you with this:
make: Leaving directory `/cygdrive/e/fptools-stage1/ghc/rts/gmp' ../../ghc/compiler/ghc-inplace -optc-mno-cygwin -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-Wcast-align -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -O2 -static -package-name rts -O -dcore-lint -c Adjustor.c -o Adjustor.o make: *** [Adjustor.o] Error 1 make: *** [all] Error 1 make: Leaving directory `/cygdrive/e/fptools-stage1/ghc' make: *** [all] Error 1
If you want to build GHC-cygwin (Section 12.1.2) you'll have to do something more like:
./configure --with-gcc=...the Cygwin gcc...
You almost certainly want to set
SplitObjs = NO
Do not attempt to build the documentation. It needs all kinds of wierd Jade stuff that we haven't worked out for Win32.