diff options
Diffstat (limited to 'docs/users_guide/installing.xml')
| -rw-r--r-- | docs/users_guide/installing.xml | 875 |
1 files changed, 875 insertions, 0 deletions
diff --git a/docs/users_guide/installing.xml b/docs/users_guide/installing.xml new file mode 100644 index 0000000000..9f8e4c9eb8 --- /dev/null +++ b/docs/users_guide/installing.xml @@ -0,0 +1,875 @@ +<?xml version="1.0" encoding="iso-8859-1"?> +<chapter id="sec-installing-bin-distrib"> + <title>Installing GHC</title> +<indexterm><primary>binary installations</primary></indexterm> +<indexterm><primary>installation, of binaries</primary></indexterm> + +<para> +Installing from binary distributions is easiest, and recommended! +(Why binaries? Because GHC is a Haskell compiler written in Haskell, +so you've got to bootstrap it somehow. We provide machine-generated +C-files-from-Haskell for this purpose, but it's really quite a pain to +use them. If you must build GHC from its sources, using a +binary-distributed GHC to do so is a sensible way to proceed. For the +other <literal>fptools</literal> programs, many are written in +Haskell, so binary distributions allow you to install them without +having a Haskell compiler.) +</para> + +<para>This guide is in several parts:</para> + + <itemizedlist> + <listitem> + <para> Installing on Unix-a-likes (<xref + linkend="sec-unix-a-likes"/>). </para> + </listitem> + <listitem> + <para> Installing on Windows (<xref + linkend="sec-install-windows"/>). </para> + </listitem> + <listitem> + <para> The layout of installed files (<xref + linkend="sec-install-files"/>). You don't need to know this to + install GHC, but it's useful if you are changing the + implementation.</para> + </listitem> + </itemizedlist> + + <sect1 id="sec-unix-a-likes"><title>Installing on Unix-a-likes</title> + + <sect2> + <title>When a platform-specific package is available</title> + + <para>For certain platforms, we provide GHC binaries packaged + using the native package format for the platform. This is + likely to be by far the best way to install GHC for your + platform if one of these packages is available, since + dependencies will automatically be handled and the package + system normally provides a way to uninstall the package at a + later date.</para> + + <para>We generally provide the following packages:</para> + + <variablelist> + <varlistentry> + <term>RedHat or SuSE Linux/x86</term> + <listitem> + <para>RPM source & binary packages for RedHat and SuSE + Linux (x86 only) are available for most major + releases.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Debian Linux/x86</term> + <listitem> + <para>Debian packages for Linux (x86 only), also for most + major releases.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>FreeBSD/x86</term> + <listitem> + <para>On FreeBSD/x86, GHC can be installed using either + the ports tree (<literal>cd /usr/ports/lang/ghc && make + install</literal>) or from a pre-compiled package + available from your local FreeBSD mirror.</para> + </listitem> + </varlistentry> + </variablelist> + + <para>Other platform-specific packages may be available, check + the GHC download page for details.</para> + </sect2> + +<sect2> +<title>GHC binary distributions</title> + +<para> +<indexterm><primary>bundles of binary stuff</primary></indexterm> +</para> + +<para> +Binary distributions come in “bundles,” one bundle per file called +<literal><replaceable>bundle</replaceable>-<replaceable>platform</replaceable>.tar.gz</literal>. (See the building guide for the definition of a platform.) Suppose that you untar a binary-distribution bundle, thus: +</para> + +<para> + +<screen> +% cd /your/scratch/space +% gunzip < ghc-x.xx-sun-sparc-solaris2.tar.gz | tar xvf -</screen> + +</para> + +<para> +Then you should find a single directory, +<literal>ghc-<replaceable>version</replaceable></literal>, with the +following structure: +</para> + +<para> +<indexterm><primary>binary distribution, layout</primary></indexterm> +<indexterm><primary>directory layout (binary distributions)</primary></indexterm> +<variablelist> + +<varlistentry> +<term><literal>Makefile.in</literal></term> +<listitem> +<para> +the raw material from which the <literal>Makefile</literal> +will be made (<xref linkend="sec-install"/>). +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>configure</literal></term> +<listitem> +<para> +the configuration script (<xref linkend="sec-install"/>). +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>README</literal></term> +<listitem> +<para> +Contains this file summary. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>INSTALL</literal></term> +<listitem> +<para> +Contains this description of how to install +the bundle. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>ANNOUNCE</literal></term> +<listitem> +<para> +The announcement message for the bundle. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>NEWS</literal></term> +<listitem> +<para> +release notes for the bundle—a longer version +of <literal>ANNOUNCE</literal>. For GHC, the release notes are contained in the User +Guide and this file isn't present. +</para> +</listitem></varlistentry> +<varlistentry> + <term><literal>bin/<replaceable>platform</replaceable></literal></term> +<listitem> +<para> +contains platform-specific executable +files to be invoked directly by the user. These are the files that +must end up in your path. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>lib/<replaceable>platform</replaceable>/</literal></term> +<listitem> +<para> +contains platform-specific support +files for the installation. Typically there is a subdirectory for +each <literal>fptools</literal> project, whose name is the name of the project with its +version number. For example, for GHC there would be a sub-directory +<literal>ghc-x.xx</literal>/ where <literal>x.xx</literal> is the version number of GHC in the bundle. +</para> + +<para> +These sub-directories have the following general structure: +</para> + +<para> +<variablelist> + +<varlistentry> +<term><literal>libHSstd.a</literal> etc:</term> +<listitem> +<para> +supporting library archives. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>ghc-iface.prl</literal> etc:</term> +<listitem> +<para> +support scripts. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>import/</literal></term> +<listitem> +<para> +<indexterm><primary>Interface files</primary></indexterm> (<literal>.hi</literal>) for the prelude. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>include/</literal></term> +<listitem> +<para> +A few C <literal>#include</literal> files. +</para> +</listitem></varlistentry> +</variablelist> +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>share/</literal></term> +<listitem> +<para> +contains platform-independent support files +for the installation. Again, there is a sub-directory for each +<literal>fptools</literal> project. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>html/</literal></term> +<listitem> +<para> +contains HTML documentation files (one +sub-directory per project). +</para> +</listitem></varlistentry> +</variablelist> +</para> + +<sect3 id="sec-install"> +<title>Installing</title> + +<para> +OK, so let's assume that you have unpacked your chosen bundles. What +next? Well, you will at least need to run the +<literal>configure</literal><indexterm><primary>configure</primary></indexterm> +script by changing directory into the top-level directory for the +bundle and typing <literal>./configure</literal>. That should convert +<literal>Makefile.in</literal> to <literal>Makefile</literal>. +</para> + +<para> +<indexterm><primary>installing in-place</primary></indexterm> +<indexterm><primary>in-place installation</primary></indexterm> +You can now either start using the tools <emphasis>in-situ</emphasis> without going +through any installation process, just type <literal>make in-place</literal> to set the +tools up for this. You'll also want to add the path which <literal>make</literal> will +now echo to your <literal>PATH</literal> environment variable. This option is useful if +you simply want to try out the package and/or you don't have the +necessary privileges (or inclination) to properly install the tools +locally. Note that if you do decide to install the package `properly' +at a later date, you have to go through the installation steps that +follow. +</para> + +<para> +To install a package, you'll have to do the following: +</para> + +<para> + +<orderedlist> +<listitem> + +<para> + Edit the <literal>Makefile</literal> and check the settings of the following variables: + +<indexterm><primary>directories, installation</primary></indexterm> +<indexterm><primary>installation directories</primary></indexterm> + +<variablelist> + +<varlistentry> +<term><literal>platform</literal></term> +<listitem> +<para> +the platform you are going to install for. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>bindir</literal></term> +<listitem> +<para> +the directory in which to install user-invokable +binaries. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>libdir</literal></term> +<listitem> +<para> +the directory in which to install +platform-dependent support files. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>datadir</literal></term> +<listitem> +<para> +the directory in which to install +platform-independent support files. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>infodir</literal></term> +<listitem> +<para> +the directory in which to install Emacs info +files. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>htmldir</literal></term> +<listitem> +<para> +the directory in which to install HTML +documentation. +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>dvidir</literal></term> +<listitem> +<para> +the directory in which to install DVI +documentation. +</para> +</listitem></varlistentry> +</variablelist> + +The values for these variables can be set through invocation of the +<command>configure</command><indexterm><primary>configure</primary></indexterm> +script that comes with the distribution, but doing an optical diff to +see if the values match your expectations is always a Good Idea. +</para> + +<para> +<emphasis>Instead of running <command>configure</command>, it is +perfectly OK to copy <filename>Makefile.in</filename> to +<filename>Makefile</filename> and set all these variables directly +yourself. But do it right!</emphasis> +</para> + +</listitem> +<listitem> + +<para> +Run <literal>make install</literal>. This <emphasis> +should</emphasis> work with ordinary Unix +<literal>make</literal>—no need for fancy stuff like GNU +<literal>make</literal>. + +</para> +</listitem> +<listitem> + +<para> +<literal>rehash</literal> (t?csh or zsh users), so your shell will see the new +stuff in your bin directory. + +</para> +</listitem> +<listitem> + +<para> + Once done, test your “installation” as suggested in +<xref linkend="sec-GHC-test"/>. Be sure to use a <literal>-v</literal> +option, so you can see exactly what pathnames it's using. + +If things don't work as expected, check the list of known pitfalls in +the building guide. +</para> +</listitem> + +</orderedlist> + +</para> + +<para> +<indexterm><primary>link, installed as ghc</primary></indexterm> +When installing the user-invokable binaries, this installation +procedure will install GHC as <literal>ghc-x.xx</literal> where <literal>x.xx</literal> is the version +number of GHC. It will also make a link (in the binary installation +directory) from <literal>ghc</literal> to <literal>ghc-x.xx</literal>. If you install multiple versions +of GHC then the last one “wins”, and “<literal>ghc</literal>” will invoke the last +one installed. You can change this manually if you want. But +regardless, <literal>ghc-x.xx</literal> should always invoke GHC version <literal>x.xx</literal>. +</para> + +</sect3> + + +<sect3> +<title>What bundles there are</title> + +<para> +<indexterm><primary>bundles, binary</primary></indexterm> There are +plenty of “non-basic” GHC bundles. The files for them are +called +<literal>ghc-x.xx-<replaceable>bundle</replaceable>-<replaceable>platform</replaceable>.tar.gz</literal>, +where the <replaceable>platform</replaceable> is as above, and +<replaceable>bundle</replaceable> is one of these: +</para> + +<para> +<variablelist> + +<varlistentry> +<term><literal>prof</literal>:</term> +<listitem> +<para> +Profiling with cost-centres. You probably want this. +<indexterm><primary>profiling bundles</primary></indexterm> +<indexterm><primary>bundles, profiling</primary></indexterm> +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>par</literal>:</term> +<listitem> +<para> +Parallel Haskell features (sits on top of PVM). +You'll want this if you're into that kind of thing. +<indexterm><primary>parallel bundles</primary></indexterm> +<indexterm><primary>bundles, parallel</primary></indexterm> +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>gran</literal>:</term> +<listitem> +<para> +The “GranSim” parallel-Haskell simulator +(hmm… mainly for implementors). +<indexterm><primary>bundles, gransim</primary></indexterm> +<indexterm><primary>gransim bundles</primary></indexterm> +</para> +</listitem></varlistentry> +<varlistentry> +<term><literal>ticky</literal>:</term> +<listitem> +<para> +“Ticky-ticky” profiling; very detailed +information about “what happened when I ran this program”—really +for implementors. +<indexterm><primary>bundles, ticky-ticky</primary></indexterm> +<indexterm><primary>ticky-ticky bundles</primary></indexterm> +</para> +</listitem></varlistentry> +</variablelist> +</para> + +<para> +One likely scenario is that you will grab <emphasis>two</emphasis> +binary bundles—basic, and profiling. We don't usually make the +rest, although you can build them yourself from a source distribution. +</para> + +<para>The various GHC bundles are designed to be unpacked into the +same directory; then installing as per the directions above will +install the whole lot in one go. Note: you <emphasis>must</emphasis> +at least have the basic GHC binary distribution bundle, these extra +bundles won't install on their own.</para> + +</sect3> + +<sect3 id="sec-GHC-test"> +<title>Testing that GHC seems to be working +</title> + +<para> +<indexterm><primary>testing a new GHC</primary></indexterm> +</para> + +<para> +The way to do this is, of course, to compile and run <emphasis>this</emphasis> program +(in a file <literal>Main.hs</literal>): +</para> + +<para> + +<programlisting> +main = putStr "Hello, world!\n" +</programlisting> + +</para> + +<para> +Compile the program, using the <literal>-v</literal> (verbose) flag to verify that +libraries, etc., are being found properly: + +<screen> +% ghc -v -o hello Main.hs</screen> + +</para> + +<para> +Now run it: + +<screen> +% ./hello +Hello, world!</screen> + +</para> + +<para> +Some simple-but-profitable tests are to compile and run the notorious +<literal>nfib</literal><indexterm><primary>nfib</primary></indexterm> program, using different numeric types. Start with +<literal>nfib :: Int -> Int</literal>, and then try <literal>Integer</literal>, <literal>Float</literal>, <literal>Double</literal>, +<literal>Rational</literal> and perhaps the overloaded version. Code for this is +distributed in <literal>ghc/misc/examples/nfib/</literal> in a source distribution. +</para> + +<para>For more information on how to “drive” GHC, read +on...</para> + +</sect3> + +</sect2> + +</sect1> + + +<sect1 id="sec-install-windows"><title>Installing on Windows</title> + +<para> +Getting the Glasgow Haskell Compiler (post 5.02) to run on Windows platforms is +a snap: the Installshield does everything you need. +</para> + +<sect2><title>Installing GHC on Windows</title> + +<para> +To install GHC, use the following steps: +</para> +<itemizedlist> +<listitem><para>Download the Installshield <filename>setup.exe</filename> +from the GHC download page +<ulink +url="http://www.haskell.org/ghc">haskell.org</ulink>. +</para></listitem> + +<listitem><para>Run <filename>setup.exe</filename>. +On Windows, all of GHC's files are installed in a single directory. +If you choose ``Custom'' from the list of install options, you will be given a +choice about where this directory is; otherwise it will be installed +in <filename>c:/ghc/<replaceable>ghc-version</replaceable></filename>. +The executable binary for GHC will be installed in the <filename>bin/</filename> sub-directory +of the installation directory you choose. +</para> +<para>(If you have already installed the same version of GHC, Installshield will offer to "modify", +or "remove" GHC. Choose "remove"; then run <filename>setup.exe</filename> a +second time. This time it should offer to install.) +</para> +<para> +When installation is complete, you should find GHCi and the GHC documentation are +available in your Start menu under "Start/Programs/Glasgow Haskell Compiler". +</para> +</listitem> + +<listitem><para> +The final dialogue box from the install process reminds you where the GHC binary +has been installed (usually <filename>c:/ghc/<replaceable>ghc-version</replaceable>/bin/</filename>. +If you want to invoke GHC from a command line, add this +to your PATH environment variable. +</para></listitem> + +<listitem><para> +GHC needs a directory in which to create, and later delete, temporary files. +It uses the standard Windows procedure <literal>GetTempPath()</literal> to +find a suitable directory. This procedure returns: +<itemizedlist> +<listitem><para>The path in environment variable TMP, +if TMP is set.</para></listitem> +<listitem><para>Otherwise, the path in environment variable TEMP, +if TEMP is set.</para></listitem> +<listitem><para>Otherwise, there is a per-user default which varies +between versions of Windows. On NT and XP-ish versions, it might +be: +<filename>c:\Documents and Settings\<username>\Local Settings\Temp</filename> +</para></listitem> +</itemizedlist> +The main point is that if you don't do anything GHC will work fine; +but if you want to control where the directory is, you can do so by +setting TMP or TEMP. +</para></listitem> + +<listitem> +<para> +To test the fruits of your labour, try now to compile a simple +Haskell program: +</para> + +<screen> +bash$ cat main.hs +module Main(main) where + +main = putStrLn "Hello, world!" +bash$ ghc -o main main.hs +.. +bash$ ./main +Hello, world! +bash$ </screen> +</listitem> +</itemizedlist> + +<para> +You do <emphasis>not</emphasis> need the Cygwin toolchain, or anything +else, to install and run GHC. +</para> +<para> +An installation of GHC requires about 140M of disk space. +To run GHC comfortably, your machine should have at least +64M of memory. +</para> +</sect2> + +<sect2><title>Moving GHC around</title> +<para> +At the moment, GHC installs in a fixed place (<filename>c:/ghc/ghc-x.yy</filename>, +but once it is installed, you can freely move the entire GHC tree just by copying +the <filename>ghc-x.yy</filename> directory. (You may need to fix up +the links in "Start/Programs/Glasgow Haskell Compiler" if you do this.) +</para> +<para> +It is OK to put GHC tree in a directory whose path involves spaces. However, +don't do this if you use want to use GHC with the Cygwin tools, +because Cygwin can get confused when this happens. +We havn't quite got to the bottom of this, but so far as we know it's not +a problem with GHC itself. Nevertheless, just to keep life simple we usually +put GHC in a place with a space-free path. +</para> +</sect2> + +<sect2 id="winfaq"> +<title>Installing ghc-win32 FAQ</title> + + <variablelist> + <varlistentry> + <term>I'm having trouble with symlinks.</term> + <listitem> + <para>Symlinks only work under Cygwin (<xref linkend="sec-install" />), so binaries not linked to the Cygwin + DLL, in particular those built for Mingwin, will not work with + symlinks.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term>I'm getting “permission denied” messages from the + <command>rm</command> or <command>mv</command>.</term> + <listitem> + <para>This can have various causes: trying to rename a directory + when an Explorer window is open on it tends to fail. Closing the + window generally cures the problem, but sometimes its cause is + more mysterious, and logging off and back on or rebooting may be + the quickest cure.</para> + </listitem> + </varlistentry> + </variablelist> + +<!-- doesn't add much value any longer; leave out [sof 7/2002]. +<para> +Further information on using GHC under Windows can be found in <ulink +url="http://www.dcs.gla.ac.uk/~sof/ghc-win32.html">Sigbjørn Finne's +pages</ulink>. Note: ignore the installation instructions, which are rather +out of date; the <emphasis>Miscellaneous</emphasis> section at the bottom of +the page is of most interest, covering topics beyond the scope of this +manual. +</para> +--> +</sect2> + +</sect1> + + +<sect1 id="sec-install-files"><title>The layout of installed files</title> + +<para> +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 +the implementation. +</para> +<para> GHC is installed in two directory trees:</para> +<variablelist> +<varlistentry> +<term>Library directory,</term> +<listitem> <para> known as <filename>$(libdir)</filename>, holds all the +support files needed to run GHC. On Unix, this +directory is usually something like <filename>/usr/lib/ghc/ghc-5.02</filename>. </para> +</listitem> +</varlistentry> +<varlistentry> +<term>Binary directory</term> +<listitem> <para> known as <filename>$(bindir)</filename>, holds executables that +the user is expected to invoke. +Notably, it contains +<filename>ghc</filename> and <filename>ghci</filename>. On Unix, this directory +can be anywhere, but is typically something like <filename>/usr/local/bin</filename>. On Windows, +however, this directory <emphasis>must be</emphasis> <filename>$(libdir)/bin</filename>. +</para> +</listitem> +</varlistentry> +</variablelist> + +<para> +When GHC runs, it must know where its library directory is. +It finds this out in one of two ways: +</para> +<itemizedlist> +<listitem> +<para> +<filename>$(libdir)</filename> is passed to GHC using the <option>-B</option> flag. +On Unix (but not Windows), the installed <filename>ghc</filename> is just a one-line +shell script that invokes the real GHC, passing a suitable <option>-B</option> flag. +[All the user-supplied flags +follow, and a later <option>-B</option> flag overrides an earlier one, so a user-supplied +one wins.] +</para> +</listitem> +<listitem> +<para> On Windows (but not Unix), if no <option>-B</option> flag is given, GHC uses a system +call to find the directory in which the running GHC executable lives, and derives +<filename>$(libdir)</filename> from that. [Unix lacks such a system call.] +That is why <filename>$(bindir)</filename> must be <filename>$(libdir)/bin</filename>. +</para> +</listitem> +</itemizedlist> + +<sect2> <title>The binary directory</title> + +<para>The binary directory, <filename>$(bindir)</filename> contains user-visible +executables, notably <filename>ghc</filename> and <filename>ghci</filename>. +You should add it to your <literal>$PATH</literal> +</para> + +<para>On Unix, the user-invokable <filename>ghc</filename> invokes <filename>$(libdir)/ghc-<replaceable>version</replaceable></filename>, +passing a suitable <option>-B</option> flag to tell <filename>ghc-<replaceable>version</replaceable></filename> where +<filename>$(libdir)</filename> is. +Similarly <filename>ghci</filename>, except the extra flag <literal>--interactive</literal> is passed. +</para> + +<para>On Win32, the user-invokable <filename>ghc</filename> binary +is the Real Thing (no intervening +shell scripts or <filename>.bat</filename> files). +Reason: we sometimes invoke GHC with very long command lines, +and <filename>cmd.exe</filename> (which executes <filename>.bat</filename> files) +truncates them. Similarly <filename>ghci</filename> is a C wrapper program that invokes <filename>ghc --interactive</filename> +(passing on all other arguments), not a <filename>.bat</filename> file. +</para> + + +</sect2> + +<sect2> <title>The library directory</title> + +<para>The layout of the library directory, <filename>$(libdir)</filename> is almost identical on +Windows and Unix, as follows. Differences between Windows and Unix +are noted thus <literal>[Win32 only]</literal> and are commented below.</para> + +<programlisting> + $(libdir)/ + package.conf GHC package configuration + ghc-usage.txt Message displayed by ghc ––help + + bin/ [Win32 only] User-visible binaries + ghc.exe + ghci.exe + + 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 + as.exe + ld.exe + + crt0.o Standard + ..etc.. binaries + + libmingw32.a Standard + ..etc.. libraries + + *.h Include files + + imports/ GHC interface files + std/*.hi 'std' library + lang/*.hi 'lang' library + ..etc.. + + include/ C header files + StgMacros.h GHC-specific + ..etc... header files + + mingw/*.h [Win32 only] Mingwin header files + + libHSrts.a GHC library archives + libHSstd.a + libHSlang.a + ..etc.. + + HSstd1.o GHC library linkables + HSstd2.o (used by ghci, which does + HSlang.o not grok .a files yet) +</programlisting> + +<para>Note that: +<itemizedlist> + + <listitem> + <para><filename>$(libdir)</filename> also contains support + binaries. These are <emphasis>not</emphasis> expected to be + on the user's <filename>PATH</filename>, but and are invoked + directly by GHC. In the Makefile system, this directory is + also called <filename>$(libexecdir)</filename>, but + <emphasis>you are not free to change it</emphasis>. It must + be the same as <filename>$(libdir)</filename>.</para> + </listitem> + +<listitem> +<para>We distribute <filename>gcc</filename> with the Win32 distribution of GHC, so that users +don't need to install <filename>gcc</filename>, nor need to care about which version it is. +All <filename>gcc</filename>'s support files are kept in <filename>$(libdir)/gcc-lib/</filename>. +</para> +</listitem> + +<listitem> +<para>Similarly, we distribute <filename>perl</filename> and a <filename>touch</filename> +replacement (<filename>touchy.exe</filename>) +with the Win32 distribution of GHC. </para> +</listitem> + + <listitem> + <para>The support programs <filename>ghc-split</filename> + and <filename>ghc-asm</filename> are Perl scripts. The + first line says <literal>#!/bin/perl</literal>; on Unix, the + script is indeed invoked as a shell script, which invokes + Perl; on Windows, GHC invokes + <filename>$(libdir)/perl.exe</filename> directly, which + treats the <literal>#!/bin/perl</literal> as a comment. + Reason: on Windows we want to invoke the Perl distributed + with GHC, rather than assume some installed one. </para> + </listitem> +</itemizedlist> +</para> + +</sect2> + +</sect1> + +</chapter> + +<!-- Emacs stuff: + ;;; Local Variables: *** + ;;; mode: xml *** + ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") *** + ;;; End: *** + --> |