This section describes what files get installed where. You don't need to know it
if you are simply installing GHC, but it is vital information if you are changing
GHC is installed in two directory trees:
known as $(bindir), holds executables that
the user is expected to invoke. Notably,
ghc and ghci. On Unix, this directory
is typically something like /usr/local/bin. On Windows,
however, this directory is always $(libdir)/bin.
known as $(libdir), holds all the
support files needed to run GHC. On Unix, this
directory is usually something like /usr/lib/ghc/ghc-5.02.
When GHC runs, it must know where its library directory is.
It finds this out in one of two ways:
$(libdir) is passed to GHC using the -B flag.
On Unix (but not Windows), the installed ghc is just a one-line
shell script that invokes the real GHC, passing a suitable -B flag.
[All the user-supplied flags
follow, and a later -B flag overrides an earlier one, so a user-supplied
On Windows (but not Unix), if no -B flag is given, GHC uses a system
call to find the directory in which the running GHC executable lives, and derives
$(libdir) from that. [Unix lacks such a system call.]
The layout of the library directory is almost identical on
Windows and Unix, as follows: layout:
package.conf GHC package configuration
ghc-usage.txt Message displayed by ghc ––help
bin/ [Win32 only] User-visible binaries
unlit Remove literate markup
touchy.exe [Win32 only]
perl.exe [Win32 only]
gcc.exe [Win32 only]
ghc-x.xx GHC executable [Unix only]
ghc-split Asm code splitter
ghc-asm Asm code mangler
gcc-lib/ [Win32 only] Support files for gcc
specs gcc configuration
cpp0.exe gcc support binaries
*.h Include files
imports/ GHC interface files
std/*.hi 'std' library
lang/*.hi 'lang' library
include/ C header files
..etc... header files
mingw/*.h [Win32 only] Mingwin header files
libHSrts.a GHC library archives
HSstd1.o GHC library linkables
HSstd2.o (used by ghci, which does
HSlang.o not grok .a files yet)
On Win32, the $(libdir)/bin directory contains user-visible binaries;
add it to your PATH. The ghci executable is a .bat
file which invokes ghc.
The GHC executable is the Real Thing (no intervening
shell scripts or .bat files).
Reason: we sometimes invoke GHC with very long command lines,
and cmd.exe (which executes .bat files)
truncates them. [We assume people won't invoke ghci with very long
On Unix, the user-invokable ghc invokes $(libdir)/ghc-version,
passing a suitable -B flag.
$(libdir) also contains support
binaries. These are not expected to be
on the user's PATH, but and are invoked
directly by GHC. In the Makefile system, this directory is
also called $(libexecdir), but
you are not free to change it. It must
be the same as $(libdir).
We distribute gcc with the Win32 distribution of GHC, so that users
don't need to install gcc, nor need to care about which version it is.
All gcc's support files are kept in $(libdir)/gcc-lib/.
Similarly, we distribute perl and a touch
with the Win32 distribution of GHC.
The support programs ghc-split
and ghc-asm are Perl scripts. The
first line says #!/bin/perl; on Unix, the
script is indeed invoked as a shell script, which invokes
Perl; on Windows, GHC invokes
$(libdir)/perl.exe directly, which
treats the #!/bin/perl as a comment.
Reason: on Windows we want to invoke the Perl distributed
with GHC, rather than assume some installed one.