supported method, and you may encounter difficulties. Full
instructions are in <xref linkend="sec-porting-ghc"/>.</para>
- <para>Which version of GHC you need will depend on the
- packages you intend to build. GHC itself will normally
- build using one of several older versions of itself - check
- the announcement or release notes for details.</para>
+ <para>GHC can be built using either an earlier released
+ version of GHC (currently 5.04 and later are supported), or
+ bootstrapped using a GHC built from exactly the same
+ sources. Note that this means you cannot in general build
+ GHC using an arbitrary development snapshot, or a build from
+ say last week. It might work, it might not - we don't
+ guarantee anything. To be on the safe side, start your
+ build using the most recently released stable version of
+ GHC.</para>
</listitem>
</varlistentry>
<para>Like the source tree, the top level of your build tree
must be (a linked copy of) the root directory of the GHC source
tree.. Inside Makefiles, the root of your build tree is called
- <constant>$(FPTOOLS_TOP)</constant><indexterm><primary>FPTOOLS_TOP</primary></indexterm>.
+ <constant>$(GHC_TOP)</constant><indexterm><primary>GHC_TOP</primary></indexterm>.
In the rest of this document path names are relative to
- <constant>$(FPTOOLS_TOP)</constant> unless
+ <constant>$(GHC_TOP)</constant> unless
otherwise stated. For example, the file
<filename>mk/target.mk</filename> is actually
- <filename>$(FPTOOLS_TOP)/mk/target.mk</filename>.</para>
+ <filename>$(GHC_TOP)/mk/target.mk</filename>.</para>
</sect2>
<sect2 id="sec-build-config">
rather than darcs sources, you can skip this step.</para>
<para>Change directory to
- <constant>$(FPTOOLS_TOP)</constant> and
+ <constant>$(GHC_TOP)</constant> and
issue the command</para>
<screen>$ autoreconf</screen>
<indexterm><primary>autoreconf</primary></indexterm>
<para>(with no arguments). This GNU program (recursively) converts
- <filename>$(FPTOOLS_TOP)/configure.ac</filename> and
- <filename>$(FPTOOLS_TOP)/aclocal.m4</filename>
+ <filename>$(GHC_TOP)/configure.ac</filename> and
+ <filename>$(GHC_TOP)/aclocal.m4</filename>
to a shell script called
- <filename>$(FPTOOLS_TOP)/configure</filename>.
+ <filename>$(GHC_TOP)/configure</filename>.
If <command>autoreconf</command> bleats that it can't write the file <filename>configure</filename>,
then delete the latter and try again. Note that you must use <command>autoreconf</command>,
and not the old <command>autoconf</command>! If you erroneously use the latter, you'll get
libraries, have their own configure script.
<command>autoreconf</command> takes care of that, too, so all you have
to do is calling <command>autoreconf</command> in the top-level directory
- <filename>$(FPTOOLS_TOP)</filename>.</para>
+ <filename>$(GHC_TOP)</filename>.</para>
<para>These steps are completely platform-independent; they just mean
that the human-written files (<filename>configure.ac</filename> and
<para>You can also use <filename>build.mk</filename> to override
anything that <command>configure</command> got wrong. One place
where this happens often is with the definition of
- <constant>FPTOOLS_TOP_ABS</constant>: this
+ <constant>GHC_TOP_ABS</constant>: this
variable is supposed to be the canonical path to the top of your
source tree, but if your system uses an automounter then the
correct directory is hard to find automatically. If you find
<para>The first thing you need to know is that <emphasis>you
must use GNU <command>make</command></emphasis>. On some
- systems this is called <command>gmake</command>, whereas on
- others it is the standard <command>make</command> command. In
- this document we will always refer to it as
+ systems (eg. FreeBSD) this is called <command>gmake</command>,
+ whereas on others it is the standard <command>make</command>
+ command. In this document we will always refer to it as
<command>make</command>; please substitute with
<command>gmake</command> if your system requires it. If you use
a the wrong <command>make</command> you will get all sorts of
<replaceable>n</replaceable> is the stage to install.</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><literal>binary-dist</literal></term>
+ <listitem>
+ <para>make a binary distribution. This is the target we
+ use to build the binary distributions of GHC.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>dist</literal></term>
+ <listitem>
+ <para>make a source distribution. Note that this target
+ does “make distclean” as part of its work;
+ don't use it if you want to keep what you've built.</para>
+ </listitem>
+ </varlistentry>
</variablelist>
<para>The top-level <filename>Makefile</filename> also arranges
<para>Invoking the <literal>boot</literal> target
explicitly is not normally necessary. From the top-level
- <literal>fptools</literal> directory, invoking
- <literal>make</literal> causes <literal>make boot
- all</literal> to be invoked in each of the project
- subdirectories, in the order specified by
- <literal>$(AllTargets)</literal> in
- <literal>config.mk</literal>.</para>
+ directory, invoking <literal>make</literal> causes
+ <literal>make boot</literal> to be invoked in various
+ subdirectories first, in the right order. Unless you
+ really know what you are doing, it is best to always say
+ <literal>make</literal> from the top level first.</para>
<para>If you're working in a subdirectory somewhere and
need to update the dependencies, <literal>make
<term><literal>uninstall</literal></term>
<listitem>
<para>reverses the effect of
- <literal>install</literal>.</para>
+ <literal>install</literal> (WARNING: probably doesn't work).</para>
</listitem>
</varlistentry>
anything that needs to exist in order to run
<filename>configure</filename> and then begin to build the
program.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><literal>check</literal></term>
- <listitem>
- <para>run the test suite.</para>
+ <para>After a <literal>maintainer-clean</literal>, a
+ <literal>configure</literal> will be necessary before
+ building again.</para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<varlistentry>
- <term><literal>configure</literal></term>
- <listitem>
- <para>is only available in the root directory
- <constant>$(FPTOOLS_TOP)</constant>; it has
- been discussed in <xref
- linkend="sec-build-config"/>.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
<term><literal>depend</literal></term>
<listitem>
<para>make a <filename>.depend</filename> file in each
file is automatically included by every Makefile.</para>
</listitem>
</varlistentry>
-
- <varlistentry>
- <term><literal>binary-dist</literal></term>
- <listitem>
- <para>make a binary distribution. This is the target we
- use to build the binary distributions of GHC and
- Happy.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>dist</literal></term>
- <listitem>
- <para>make a source distribution. Note that this target
- does “make distclean” as part of its work;
- don't use it if you want to keep what you've built.</para>
- </listitem>
- </varlistentry>
</variablelist>
- <para>Most <filename>Makefile</filename>s have targets other
+ <para>Some <filename>Makefile</filename>s have targets other
than these. You can discover them by looking in the
<filename>Makefile</filename> itself.</para>
</sect2>
<sect2>
- <title>Using a project from the build tree</title>
+ <title>Using GHC from the build tree</title>
- <para>If you want to build GHC (say) and just use it direct from
- the build tree without doing <literal>make install</literal>
- first, you can run the in-place driver script:
- <filename>compiler/ghc-inplace</filename>.</para>
+ <para>If you want to build GHC and just use it direct from the
+ build tree without doing <literal>make install</literal> first,
+ you can run the in-place driver script. To run the stage 1
+ compiler, use <filename>compiler/stage1/ghc-inplace</filename>,
+ stage 2 is <filename>compiler/stage2/ghc-inplace</filename>, and
+ so on.</para>
<para> Do <emphasis>NOT</emphasis> use
- <filename>compiler/ghc</filename>, or
- <filename>compiler/ghc-6.xx</filename>, as these are the
+ <filename>compiler/stage1/ghc</filename>, or
+ <filename>compiler/stage1/ghc-6.xx</filename>, as these are the
scripts intended for installation, and contain hard-wired paths
to the installed libraries, rather than the libraries in the
build tree.</para>
-
- <para>Happy can similarly be run from the build tree, using
- <filename>happy/src/happy-inplace</filename>, and similarly for
- Alex and Haddock.</para>
</sect2>
<sect2>
</sect2>
<sect2>
- <title>A small project</title>
+ <title>A small example</title>
<para>To get started, let us look at the
- <filename>Makefile</filename> for an imaginary small
- <literal>fptools</literal> project, <literal>small</literal>.
- Each project in <literal>fptools</literal> has its own directory
- in <constant>FPTOOLS_TOP</constant>, so the
- <literal>small</literal> project will have its own directory
- <constant>FPOOLS_TOP/small/</constant>. Inside the
- <filename>small/</filename> directory there will be a
+ <filename>Makefile</filename> for an imaginary small program,
+ <literal>small</literal>. Each program or library in the GHC
+ source tree typically has its own directory, in this case we'll
+ use <filename>$(GHC_TOP)/small</filename>.
+ Inside the <filename>small/</filename> directory there will be a
<filename>Makefile</filename>, looking something like
this:</para>
<indexterm><primary>Makefile, minimal</primary></indexterm>
-<programlisting># Makefile for fptools project "small"
-
+<programlisting># Makefile for program "small"
TOP = ..
include $(TOP)/mk/boilerplate.mk
-SRCS = $(wildcard *.lhs) $(wildcard *.c)
HS_PROG = small
include $(TOP)/target.mk</programlisting>
</para>
</footnote>
- a file of “boilerplate” code from the level
- above (which in this case will be
- <filename>FPTOOLS_TOP/mk/boilerplate.mk</filename><indexterm><primary>boilerplate.mk</primary></indexterm>).
+ a file of “boilerplate” code from the top level
+ <indexterm><primary>boilerplate.mk</primary></indexterm>).
As its name suggests, <filename>boilerplate.mk</filename>
consists of a large quantity of standard
<filename>Makefile</filename> code. We discuss this
<para>Before the <literal>include</literal> statement, you
must define the <command>make</command> variable
<constant>TOP</constant><indexterm><primary>TOP</primary></indexterm>
- to be the directory containing the <filename>mk</filename>
+ to be the top-level directory of the source tree, containing
+ the <filename>mk</filename>
directory in which the <filename>boilerplate.mk</filename>
file is. It is <emphasis>not</emphasis> OK to simply say</para>
<programlisting>include ../mk/boilerplate.mk # NO NO NO</programlisting>
-
<para>Why? Because the <filename>boilerplate.mk</filename>
file needs to know where it is, so that it can, in turn,
<literal>include</literal> other files. (Unfortunately,
refers to itself.</emphasis> It is up to the
<filename>Makefile</filename> doing the
<literal>include</literal> to ensure this is the case.</para>
-
- <para>Files intended for inclusion in other
- <filename>Makefile</filename>s are written to have the
- following property: <emphasis>after
- <filename>foo.mk</filename> is <literal>include</literal>d,
- it leaves <constant>TOP</constant> containing the same value
- as it had just before the <literal>include</literal>
- statement</emphasis>. In our example, this invariant
- guarantees that the <literal>include</literal> for
- <filename>target.mk</filename> will look in the same
- directory as that for <filename>boilerplate.mk</filename>.</para>
</listitem>
<listitem>
- <para> The second section defines the following standard
- <command>make</command> variables:
- <constant>SRCS</constant><indexterm><primary>SRCS</primary></indexterm>
- (the source files from which is to be built), and
+ <para> The second section defines the standard
+ <command>make</command> variable
<constant>HS_PROG</constant><indexterm><primary>HS_PROG</primary></indexterm>
(the executable binary to be built). We will discuss in
more detail what the “standard variables” are,
and how they affect what happens, in <xref
linkend="sec-targets"/>.</para>
-
- <para>The definition for <constant>SRCS</constant> uses the
- useful GNU <command>make</command> construct
- <literal>$(wildcard $pat$)</literal><indexterm><primary>wildcard</primary></indexterm>,
- which expands to a list of all the files matching the
- pattern <literal>pat</literal> in the current directory. In
- this example, <constant>SRCS</constant> is set to the list
- of all the <filename>.lhs</filename> and
- <filename>.c</filename> files in the directory. (Let's
- suppose there is one of each, <filename>Foo.lhs</filename>
- and <filename>Baz.c</filename>.)</para>
</listitem>
<listitem>
<itemizedlist>
<listitem>
- <para><command>make</command> figures out that the object
- files are <filename>Foo.o</filename> and
- <filename>Baz.o</filename>.</para>
+ <para><command>make</command> looks in the current directory
+ to see what source files it can find
+ (eg. <filename>Foo.hs</filename>,
+ <filename>Baz.c</filename>), and from that it figures out
+ what object files need to be built
+ (eg. <filename>Foo.o</filename>,
+ <filename>Baz.o</filename>). Because source files are found
+ and used automatically, omitting them from a program or
+ library has to be done manually (see
+ <literal>EXCLUDED_SRCS</literal> in <xref
+ linkend="sec-boiler" />).</para>
</listitem>
<listitem>
<para>It uses a boilerplate pattern rule to compile
- <filename>Foo.lhs</filename> to <filename>Foo.o</filename>
+ <filename>Foo.hs</filename> to <filename>Foo.o</filename>
using a Haskell compiler. (Which one? That is set in the
build configuration.)</para>
</listitem>
three-section format.</para>
</sect2>
- <sect2>
- <title>A larger project</title>
-
- <para>Larger projects are usually structured into a number of
- sub-directories, each of which has its own
- <filename>Makefile</filename>. (In very large projects, this
- sub-structure might be iterated recursively, though that is
- rare.) To give you the idea, here's part of the directory
- structure for the (rather large) GHC project:</para>
-
-<programlisting>$(FPTOOLS_TOP)/ghc/
- Makefile
- mk/
- boilerplate.mk
- rules.mk
- docs/
- Makefile
- ...source files for documentation...
- driver/
- Makefile
- ...source files for driver...
- compiler/
- Makefile
- parser/...source files for parser...
- renamer/...source files for renamer...
- ...etc...</programlisting>
-
- <para>The sub-directories <filename>docs</filename>,
- <filename>driver</filename>, <filename>compiler</filename>, and
- so on, each contains a sub-component of GHC, and each has its
- own <filename>Makefile</filename>. There must also be a
- <filename>Makefile</filename> in
- <filename>$(FPTOOLS_TOP)/ghc</filename>.
- It does most of its work by recursively invoking
- <command>make</command> on the <filename>Makefile</filename>s
- in the sub-directories. We say that
- <filename>ghc/Makefile</filename> is a <emphasis>non-leaf
- <filename>Makefile</filename></emphasis>, because it does little
- except organise its children, while the
- <filename>Makefile</filename>s in the sub-directories are all
- <emphasis>leaf <filename>Makefile</filename>s</emphasis>. (In
- principle the sub-directories might themselves contain a
- non-leaf <filename>Makefile</filename> and several
- sub-sub-directories, but that does not happen in GHC.)</para>
-
- <para>The <filename>Makefile</filename> in
- <filename>ghc/compiler</filename> is considered a leaf
- <filename>Makefile</filename> even though the
- <filename>ghc/compiler</filename> has sub-directories, because
- these sub-directories do not themselves have
- <filename>Makefile</filename>s in them. They are just used to
- structure the collection of modules that make up GHC, but all
- are managed by the single <filename>Makefile</filename> in
- <filename>ghc/compiler</filename>.</para>
-
- <para>You will notice that <filename>ghc/</filename> also
- contains a directory <filename>ghc/mk/</filename>. It contains
- GHC-specific <filename>Makefile</filename> boilerplate code.
- More precisely:</para>
-
- <itemizedlist>
- <listitem>
- <para><filename>ghc/mk/boilerplate.mk</filename> is included
- at the top of <filename>ghc/Makefile</filename>, and of all
- the leaf <filename>Makefile</filename>s in the
- sub-directories. It in turn <literal>include</literal>s the
- main boilerplate file
- <filename>mk/boilerplate.mk</filename>.</para>
- </listitem>
-
- <listitem>
- <para><filename>ghc/mk/target.mk</filename> is
- <literal>include</literal>d at the bottom of
- <filename>ghc/Makefile</filename>, and of all the leaf
- <filename>Makefile</filename>s in the sub-directories. It
- in turn <literal>include</literal>s the file
- <filename>mk/target.mk</filename>.</para>
- </listitem>
- </itemizedlist>
-
- <para>So these two files are the place to look for GHC-wide
- customisation of the standard boilerplate.</para>
- </sect2>
-
<sect2 id="sec-boiler-arch">
<title>Boilerplate architecture</title>
<indexterm><primary>boilerplate architecture</primary></indexterm>
</sect2>
<sect2 id="sec-boiler">
- <title>The main <filename>mk/boilerplate.mk</filename> file</title>
+ <title>The <filename>mk/boilerplate.mk</filename> file</title>
<indexterm><primary>boilerplate.mk</primary></indexterm>
<para>If you look at
- <filename>$(FPTOOLS_TOP)/mk/boilerplate.mk</filename>
+ <filename>$(GHC_TOP)/mk/boilerplate.mk</filename>
you will find that it consists of the following sections, each
held in a separate file:</para>
<para>extra options to pass to all C compilations. This
is intended for command line use, thus:</para>
-<screen>$ make libHS.a EXTRA_CC_OPTS="-v"</screen>
+<screen>$ make libHS.a EXTRA_HC_OPTS="-v"</screen>
</listitem>
</varlistentry>
</variablelist>
<constant>$(libdir)</constant>.</para>
</listitem>
</varlistentry>
-
- <varlistentry>
- <term><constant>LIB_DATA</constant><indexterm><primary>LIB_DATA</primary></indexterm></term>
- <listitem>
- <para>…</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><constant>LIB_EXEC</constant><indexterm><primary>LIB_EXEC</primary></indexterm></term>
- <listitem>
- <para>…</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><constant>HS_SRCS</constant><indexterm><primary>HS_SRCS</primary></indexterm>, <constant>C_SRCS</constant><indexterm><primary>C_SRCS</primary></indexterm>.</term>
- <listitem>
- <para>If <constant>HS_SRCS</constant> is defined
- and non-empty, a rule for the target
- <literal>depend</literal> is included, which generates
- dependency information for Haskell programs. Similarly
- for <constant>C_SRCS</constant>.</para>
- </listitem>
- </varlistentry>
</variablelist>
- <para>All of these rules are “double-colon” rules,
+ <para>Some rules are “double-colon” rules,
thus</para>
<programlisting>install :: $(HS_PROG)
<title>Tools for building the Documentation</title>
<para>The following additional tools are required if you want to
- format the documentation that comes with the
- <literal>fptools</literal> projects:</para>
+ format the documentation that comes with GHC:</para>
<variablelist>
<varlistentry>
<listitem>
<para>Haddock is a Haskell documentation tool that we use
for automatically generating documentation from the
- library source code. It is an <literal>fptools</literal>
- project in itself. To build documentation for the
- libraries (<literal>fptools/libraries</literal>) you
- should check out and build Haddock in
- <literal>fptools/haddock</literal>. Haddock requires GHC
+ library source code. To build documentation for the
+ libraries (<literal>$(GHC_TOP)/libraries</literal>) you
+ should build and install Haddock. Haddock requires GHC
to build.</para>
</listitem>
</varlistentry>
<title>Porting GHC</title>
<para>This section describes how to port GHC to a currenly
- unsupported platform. There are two distinct
- possibilities:</para>
+ unsupported platform. To avoid confusion, when we say
+ “architecture” we are referring to the processor, and
+ we use the term “platform” to refer to the combination
+ of architecture and operating system.</para>
+
+ <para>There are two distinct porting scenarios:</para>
<itemizedlist>
<listitem>
- <para>The hardware architecture for your system is already
- supported by GHC, but you're running an OS that isn't
- supported (or perhaps has been supported in the past, but
- currently isn't). This is the easiest type of porting job,
- but it still requires some careful bootstrapping. Proceed to
- <xref linkend="sec-booting-from-hc"/>.</para>
+ <para>Your platform is already supported, but you want to
+ compile up GHC using just a C compiler. This is a
+ straightforward bootstrap from HC files, and is described in
+ <xref linkend="sec-booting-from-hc" />.</para>
</listitem>
<listitem>
- <para>Your system's hardware architecture isn't supported by
- GHC. This will be a more difficult port (though by comparison
- perhaps not as difficult as porting gcc). Proceed to <xref
- linkend="unregisterised-porting"/>.</para>
+ <para>Your platform isn't supported by GHC. You will need to
+ do an <emphasis>unregisterised bootstrap</emphasis>, proceed
+ to <xref linkend="unregisterised-porting"/>.</para>
</listitem>
</itemizedlist>
later.</emphasis></para>
<para>HC files are platform-dependent, so you have to get a set
- that were generated on <emphasis>the same platform</emphasis>. There
- may be some supplied on the GHC download page, otherwise you'll have to
- compile some up yourself, or start from
- <emphasis>unregisterised</emphasis> HC files - see <xref
- linkend="unregisterised-porting"/>.</para>
+ that were generated on <emphasis>the same platform</emphasis>.
+ There may be some supplied on the GHC download page, otherwise
+ you'll have to compile some up yourself.</para>
<para>The following steps should result in a working GHC build
with full libraries:</para>
<itemizedlist>
<listitem>
- <para>Unpack the HC files on top of a fresh source tree
- (make sure the source tree version matches the version of
- the HC files <emphasis>exactly</emphasis>!). This will
- place matching <filename>.hc</filename> files next to the
- corresponding Haskell source (<filename>.hs</filename> or
- <filename>.lhs</filename>) in the compiler subdirectory
- <filename>ghc/compiler</filename> and in the libraries
- (subdirectories of
+ <para>Make a set of HC files. On an identical system with
+ GHC already installed, get a GHC source tree and put the
+ following in <literal>mk/build.mk</literal>:</para>
+
+<programlisting>
+SRC_HC_OPTS = -H32m -O -fasm -Rghc-timing -keep-hc-files
+GhcLibHcOpts = -O
+GhcLibWays =
+SplitObjs = NO
+</programlisting>
+
+ <para>Build GHC as normal, and then <literal>make
+ hc-file-bundle Project=ghc</literal> to creates the tar file
+ containing the hc files.</para>
+ </listitem>
+
+ <listitem>
+ <para>On the target system, unpack the HC files on top of a
+ fresh source tree (make sure the source tree version matches
+ the version of the HC files <emphasis>exactly</emphasis>!).
+ This will place matching <filename>.hc</filename> files next
+ to the corresponding Haskell source
+ (<filename>.hs</filename> or <filename>.lhs</filename>) in
+ the compiler subdirectory <filename>ghc/compiler</filename>
+ and in the libraries (subdirectories of
<literal>libraries</literal>).</para>
</listitem>
</sect2>
<sect2 id="unregisterised-porting">
- <title>Porting GHC to a new architecture</title>
+ <title>Porting GHC to a new platform</title>
- <para>The first step in porting to a new architecture is to get
- an <firstterm>unregisterised</firstterm> build working. An
+ <para>The first step in porting to a new platform is to get an
+ <firstterm>unregisterised</firstterm> build working. An
unregisterised build is one that compiles via vanilla C only.
By contrast, a registerised build uses the following
architecture-specific hacks for speed:</para>
since unregisterised compilation is usually just a step on the
way to a full registerised port, we don't mind too much.</para>
+ <para>You should go through this process even if your
+ architecture is already has registerised support in GHC, but
+ your OS currently isn't supported. In this case you probably
+ won't need to port any of the architecture-specific parts of the
+ code, and you can proceed straight from the unregisterised build
+ to build a registerised compiler.</para>
+
<para>Notes on GHC portability in general: we've tried to stick
to writing portable code in most parts of the system, so it
should compile on any POSIXish system with gcc, but in our
<para>You might need to update
<filename>configure.in</filename> to recognise the new
- architecture, and re-generate
+ platform, and re-generate
<filename>configure</filename> with
<literal>autoreconf</literal>.</para>
</listitem>
$ make clean
$ rm .depend
$ make boot UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'
-$ cd <replaceable>H</replaceable>/ghc/utils
+$ cd <replaceable>H</replaceable>/utils
$ make clean
$ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'</screen>
</listitem>
<title>GHCi</title>
<para>To support GHCi, you need to port the dynamic linker
- (<filename>fptools/ghc/rts/Linker.c</filename>). The linker
- currently supports the ELF and PEi386 object file formats - if
- your platform uses one of these then things will be
- significantly easier. The majority of Unix platforms use the
- ELF format these days. Even so, there are some
+ (<filename>$(GHC_TOP)/rts/Linker.c</filename>). The
+ linker currently supports the ELF and PEi386 object file
+ formats - if your platform uses one of these then things will
+ be significantly easier. The majority of Unix platforms use
+ the ELF format these days. Even so, there are some
machine-specific parts of the ELF linker: for example, the
code for resolving particular relocation types is
machine-specific, so some porting of this code to your
- architecture will probaly be necessary.</para>
+ architecture and/or OS will probaly be necessary.</para>
<para>If your system uses a different object file format, then
you have to write a linker — good luck!</para>
<programlisting>export TMPDIR=<dir></programlisting>
-in your <filename>build.mk</filename> file.
-Then GHC and the other <literal>fptools</literal> programs will use the appropriate directory
-in all cases.
+in your <filename>build.mk</filename> file. Then GHC and the other
+tools will use the appropriate directory in all cases.
</para>
<para>You have to install the following other things to build GHC, listed below.</para>
<para>On Windows you often install executables in directories with spaces, such as
-"<filename>Program Files</filename>". However, the <literal>make</literal> system for fptools doesn't
+"<filename>Program Files</filename>". However, the <literal>make</literal> system doesn't
deal with this situation (it'd have to do more quoting of binaries), so you are strongly advised
to put binaries for all tools in places with no spaces in their path.
On both MSYS and Cygwin, it's perfectly OK to install such programs in the standard Unixy places,
<listitem>
<para>We use <command>emacs</command> a lot, so we install that too.
-When you are in <filename>fptools/ghc/compiler</filename>, you can use
+When you are in <filename>$(GHC_TOP)/compiler</filename>, you can use
"<literal>make tags</literal>" to make a TAGS file for emacs. That uses the utility
-<filename>fptools/ghc/utils/hasktags/hasktags</filename>, so you need to make that first.
-The most convenient way to do this is by going <literal>make boot</literal> in <filename>fptools/ghc</filename>.
+<filename>$(GHC_TOP)/ghc/utils/hasktags/hasktags</filename>, so you need to make that first.
+The most convenient way to do this is by going <literal>make boot</literal> in <filename>$(GHC_TOP)/ghc</filename>.
The <literal>make tags</literal> command also uses <command>etags</command>, which comes with <command>emacs</command>,
so you will need to add <filename>emacs/bin</filename> to your <literal>PATH</literal>.
</para>
<listitem>
<para>
After <command>autoreconf</command> run <command>./configure</command> in
- <filename>fptools/</filename> thus:
+ <filename>$(GHC_TOP)/</filename> thus:
<screen>$ ./configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc</screen>
This is the point at which you specify that you are building GHC-mingw
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:
-<screen>make[4]: Leaving directory `/cygdrive/e/fptools-stage1/ghc/rts/gmp'
+<screen>make[4]: Leaving directory `/cygdrive/e/ghc-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
-package-name rts -O -dcore-lint -c Adjustor.c -o Adjustor.o
make[2]: *** [Adjustor.o] Error 1
make[1]: *** [all] Error 1
-make[1]: Leaving directory `/cygdrive/e/fptools-stage1/ghc'
+make[1]: Leaving directory `/cygdrive/e/ghc-stage1/ghc'
make: *** [all] Error 1</screen>
Be warned!
</para>
; also, subscribe to cvs-all@haskell.org, or follow the mailing list
; archive, in case you checkout a version with problems
; http://www.haskell.org//pipermail/cvs-all/
- - mkdir c:/fptools; cd c:/fptools
+ - mkdir c:/ghc-build; cd c:/ghc-build
; (or whereever you want your darcs tree to be)
- darcs get http://darcs.haskell.org/ghc
- cd ghc
; for haddock, alex, happy (*)
- export PATH=/cygdrive/c/mingw/bin:$PATH
; without, we pick up some cygwin tools at best!
- - cd c:/fptools/fptools
+ - cd c:/ghc-build
; (if you aren't there already)
- autoreconf
- ./configure --host=i386-unknown-mingw32 --with-gcc=C:/Mingw/bin/gcc.exe
projects / ghc-hetmet.git / blobdiff