<para>
- [Windows users.] The programs <command>ssh-keygen1</command>, <command>ssh1</command>, and <command>cvs</command>,
- seem to lock up <command>bash</command> entirely if they try to get user input (e.g. if
- they ask for a password). To solve this, start up <filename>cmd.exe</filename>
- and run it as follows:
- <Screen>
- c:\tmp> set CYGWIN32=tty
- c:\tmp> c:/user/local/bin/ssh-keygen1
- </Screen> </para>
+ <emphasis>Windows users: see the notes in <xref linkend="configure-ssh"> about <command>ssh</command> wrinkles!</emphasis>
+ </para>
+
- <para>[Windows users.] To protect your
- <literal>.ssh</literal> from access by anyone else,
- right-click your <literal>.ssh</literal> directory, and
- select <literal>Properties</literal>. 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!</para>
- <para>[March 2003] In fact <command>ssh</command> 3.6.1 now seems to <emphasis>require</emphasis>
- you to have Unix permissions 600 (read/write for owner only)
- on the <literal>.ssh/identity</literal> file, else it
- bombs out. For your local C drive, it seems that <literal>chmod 600 identity</literal> 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 "<literal>ntsec neta</literal>". The CYGWIN environment variable is discussed
- in <ulink url="http://cygwin.com/cygwin-ug-net/using-cygwinenv.html">the Cygwin User's Guide</ulink>,
- and there are more details in <ulink url="http://cygwin.com/faq/faq_4.html#SEC44">the Cygwin FAQ</ulink>.
- </para>
</listitem>
<listitem>
<literal>hslibs</literal> and <literal>libraries</literal>
modules (for a full list of the projects available, see
<xref linkend="projects">).</para>
+
+ <para>Remember that if you do not have
+ <literal>happy</literal> installed, you need to check it out
+ as well.</para>
</listitem>
</itemizedlist>
</sect2>
you the results.</para>
</listitem>
- <listitem>
+ <listitem>
+ <para>If you changed something in the
+ <literal>fptools/libraries</literal> subdirectories, also run
+ <literal>make html</literal> to check if the documentation can
+ be generated successfully, too.</para>
+ </listitem>
+
+ <listitem>
<para>Before checking in a change, you need to update your
source tree:</para>
major cause of headaches. </para>
<para>So, to avoid a lot of hassle, follow this recipe for
- updating your tree: </para>
+ updating your tree:</para>
<screen>
$ cd fptools
-$ cvs update -Pd 2>&1 | tee log</screen>
+$ cvs update -P 2>&1 | tee log</screen>
<para>Look at the log file, and fix any conflicts (denoted by a
- <quote>C</quote> in the first column). If you're using multiple
- build trees, then for every build tree you have pointing at this
- source tree, you need to update the links in case any new files
- have appeared: </para>
+ <quote>C</quote> in the first column). New directories may have
+ appeared in the repository; CVS doesn't check these out by
+ default, so to get new directories you have to explicitly do
+<screen>
+$ cvs update -d</screen>
+ in each project subdirectory. Don't do this at the top level,
+ because then <emphasis>all</emphasis> the projects will be
+ checked out.</para>
+
+ <para>If you're using multiple build trees, then for every build
+ tree you have pointing at this source tree, you need to update
+ the links in case any new files have appeared: </para>
<screen>
$ cd <replaceable>build-tree</replaceable>
</varlistentry>
<varlistentry>
- <term><literal>green-card</literal></term>
- <indexterm><primary><literal>green-card</literal></primary><secondary>project</secondary></indexterm>
+ <term><literal>greencard</literal></term>
+ <indexterm><primary><literal>greencard</literal></primary><secondary>project</secondary></indexterm>
<listitem>
<para>The <ulink
- url="http://www.haskell.org/greencard/">Green Card</ulink>
+ url="http://www.haskell.org/greencard/">GreenCard</ulink>
system for generating Haskell foreign function
interfaces.</para>
</listitem>
<command>egcs</command>) have varying degrees of stability
depending on the platform.</para>
+ <para>GCC 3.2 is currently known to have problems building
+ GHC on Sparc, but is stable on x86.</para>
+
+ <para>GCC 3.3 currently cannot be used to build GHC, due to
+ some problems with the new C preprocessor.</para>
+
<para>If your GCC dies with “internal error” on
some GHC source file, please let us know, so we can report
it and get things improved. (Exception: on iX86
(<literal>fptools/happy</literal>). It can be built from
source, but bear in mind that you'll need GHC installed in
order to build it. To avoid the chicken/egg problem,
- install a binary distribtion of either Happy or GHC to get
+ install a binary distribution of either Happy or GHC to get
started. Happy distributions are available from <ulink
url="http://www.haskell.org/happy/">Happy's Web
Page</ulink>.</para>
CVS sources, it is <emphasis>not</emphasis> needed if you
just intend to build a standard source distribution.</para>
+ <para>Version 2.52 or later of autoconf is required.
+ NB. vesrion 2.13 will no longer work, as of GHC version
+ 6.1.</para>
+
<para>Autoconf builds the <command>configure</command>
- script from <filename>configure.in</filename> and
+ script from <filename>configure.ac</filename> and
<filename>aclocal.m4</filename>. If you modify either of
these files, you'll need <command>autoconf</command> to
rebuild <filename>configure</filename>.</para>
<listitem>
<para>PVM is the Parallel Virtual Machine on which
Parallel Haskell programs run. (You only need this if you
- plan to run Parallel Haskell. Concurent Haskell, which
+ plan to run Parallel Haskell. Concurrent Haskell, which
runs concurrent threads on a uniprocessor doesn't need
it.) Underneath PVM, you can have (for example) a network
of workstations (slow) or a multiprocessor box
</listitem>
<listitem>
- <para><filename>configure.in</filename>,
+ <para><filename>configure.ac</filename>,
<filename>config.sub</filename>,
<filename>config.guess</filename>: these files support the
configuration process.</para>
only one project (<literal>happy</literal>, say), you must have
a source tree whose root directory contains
<filename>Makefile</filename>, <filename>mk/</filename>,
- <filename>configure.in</filename>, and the project(s) you want
+ <filename>configure.ac</filename>, and the project(s) you want
(<filename>happy/</filename> in this case). You cannot get by
with just the <filename>happy/</filename> directory.</para>
</sect2>
issue the command
<command>autoconf</command><indexterm><primary>autoconf</primary></indexterm>
(with no arguments). This GNU program converts
- <filename><constant>$(FPTOOLS_TOP)</constant>/configure.in</filename>
+ <filename><constant>$(FPTOOLS_TOP)</constant>/configure.ac</filename>
to a shell script called
<filename><constant>$(FPTOOLS_TOP)</constant>/configure</filename>.
</para>
<para>Some projects, including GHC, have their own
configure script. If there's an
- <constant>$(FPTOOLS_TOP)/<project>/configure.in</constant>,
+ <constant>$(FPTOOLS_TOP)/<project>/configure.ac</constant>,
then you need to run <command>autoconf</command> in that
directory too.</para>
<para>Both these steps are completely
platform-independent; they just mean that the
- human-written file (<filename>configure.in</filename>) can
+ human-written file (<filename>configure.ac</filename>) can
be short, although the resulting shell script,
<command>configure</command>, and
<filename>mk/config.h.in</filename>, are long.</para>
round your computer working out what architecture it has,
what operating system, whether it has the
<Function>vfork</Function> system call, where
- <command>yacc</command> is kept, whether
+ <command>tar</command> is kept, whether
<command>gcc</command> is available, where various obscure
<literal>#include</literal> files are, whether it's a
leap year, and what the systems manager had for lunch. It
includes <filename>build.mk</filename> after
<filename>config.mk</filename>.)</para>
+ <para>For your convenience, there's a file called <filename>build.mk.sample</filename>
+ that can serve as a starting point for your <filename>build.mk</filename>.</para>
+
<para>For example, <filename>config.mk.in</filename> contains
the definition:</para>
For example, there's a line that says:</para>
<ProgramListing>
-YACC = @YaccCmd@
+TAR = @TarCmd@
</ProgramListing>
- <para>This defines the Make variables <constant>YACC</constant>
- to the pathname for a <command>yacc</command> that
+ <para>This defines the Make variables <constant>TAR</constant>
+ to the pathname for a <command>tar</command> that
<command>configure</command> finds somewhere. If you have your
- own pet <command>yacc</command> you want to use instead, that's
+ own pet <command>tar</command> you want to use instead, that's
fine. Just add this line to <filename>mk/build.mk</filename>:</para>
<ProgramListing>
-YACC = myyacc
+TAR = mytar
</ProgramListing>
<para>You do not <emphasis>have</emphasis> to have a
<para> Do <emphasis>NOT</emphasis> use
<filename>ghc/compiler/ghc</filename>, or
- <filename>ghc/compiler/ghc-5.xx</filename>, as these are the
+ <filename>ghc/compiler/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>
target machine, and compiling them using gcc to get a working
GHC.</para>
- <para><emphasis>NOTE: GHC version 5.xx is significantly harder
- to bootstrap from C than previous versions. We recommend
- starting from version 4.08.2 if you need to bootstrap in this
- way.</emphasis></para>
+ <para><emphasis>NOTE: GHC versions 5.xx and later are
+ significantly harder to bootstrap from C than earlier versions.
+ We recommend starting from version 4.08.2 if you need to
+ bootstrap in this way.</emphasis></para>
<para>HC files are architecture-dependent (but not
OS-dependent), so you have to get a set that were generated on
</programlisting>
<programlisting>
-# build.mk for GHC 5.xx
+# build.mk for GHC 5.xx and 6.x
GhcUnregisterised=YES
</programlisting>
- <para>Version 5.xx only: use the option
+ <para>Versions 5.xx and 6.x only: use the option
<option>--enable-hc-boot-unregisterised</option> instead of
<option>--enable-hc-boot</option> when running
<filename>./configure</filename>.</para>
<itemizedlist>
<listitem>
<para>
+By default, cygwin provides the command shell <filename>ash</filename>
+as <filename>sh.exe</filename>. We have often seen build-system problems that
+turn out to be due to bugs in <filename>ash</filename>
+(to do with quoting
+and length of command lines). On the other hand <filename>bash</filename> seems
+to be rock solid.
+So, in <filename>cygwin/bin</filename>
+remove the supplied <filename>sh.exe</filename> (or rename it as <filename>ash.exe</filename>),
+and copy <filename>bash.exe</filename> to <filename>sh.exe</filename>.
+You'll need to do this in Windows Explorer or the Windows <command>cmd</command> shell, because
+you can't rename a running program!
+</para>
+</listitem>
+
+<listitem>
+<para>
Some script files used in the make system start with "<Command>#!/bin/perl</Command>",
-(and similarly for <Command>bash</Command>). Notice the hardwired path!
+(and similarly for <Command>sh</Command>). Notice the hardwired path!
So you need to ensure that your <Filename>/bin</Filename> directory has the following
binaries in it:
<itemizedlist>
installed as <Filename>c:/cygwin/bin</Filename>. By default Cygwin mounts "<Filename>/</Filename>" as
<Filename>c:/cygwin</Filename>, so if you just take the defaults it'll all work ok.
(You can discover where your Cygwin
-root directory <Filename>/</Filename> is by typing <Command>mount</Command>).
+root directory <Filename>/</Filename> is by typing <Command>mount</Command>.)
Provided <Filename>/bin</Filename> points to the Cygwin <Filename>bin</Filename>
-directory, there's no need to copy anything.
-</para>
-</listitem>
-
-<listitem>
-<para>
-By default, cygwin provides the command shell <filename>ash</filename>
-as <filename>sh.exe</filename>. It has a couple of 'issues' (to do with quoting
-and length of command lines), so
-in your <filename>/bin</filename> directory, make sure that <filename>
-bash.exe</filename> is also provided as <filename>sh.exe</filename>
-(i.e. overwrite the old <filename>sh.exe</filename> with a copy of
-<filename>bash.exe</filename>).
+directory, there's no need to copy anything. If not, copy these binaries from the <filename>cygwin/bin</filename>
+directory (after fixing the <filename>sh.exe</filename> stuff mentioned in the previous bullet).
</para>
</listitem>
</itemizedlist>
</Sect2>
+<Sect2 id="configure-ssh"><Title>Configuring SSH</Title>
+
+<para><command>ssh</command> comes with Cygwin, provided you remember to ask for it when
+you install Cygwin. (If not, the installer lets you update easily.) Look for <command>openssh</command>
+(not ssh) in the Cygwin list of applications!</para>
+
+<para>There are several strange things about <command>ssh</command> on Windows that you need to know.
+<itemizedlist>
+<listitem>
+<para>
+ The programs <command>ssh-keygen1</command>, <command>ssh1</command>, and <command>cvs</command>,
+ seem to lock up <command>bash</command> entirely if they try to get user input (e.g. if
+ they ask for a password). To solve this, start up <filename>cmd.exe</filename>
+ and run it as follows:
+ <Screen>
+ c:\tmp> set CYGWIN32=tty
+ c:\tmp> c:/user/local/bin/ssh-keygen1
+ </Screen> </para>
+</listitem>
+
+<listitem><para>
+<command>ssh</command> needs to access your directory <filename>.ssh</filename>, in your home directory.
+To determine your home directory <command>ssh</command> first looks in
+<filename>c:/cygwin/etc/passwd</filename> (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, <emphasis>ignoring
+the setting of the environment variable $HOME</emphasis>. If the home directory is
+bogus, <command>ssh</command> fails horribly. The best way to see what is going on is to say
+<programlisting>
+ ssh -v cvs.haskell.org
+</programlisting>
+which makes <command>ssh</command> print out information about its activity.
+</para>
+<para> You can fix this problem, either by correcting the home-directory field in
+<filename>c:/cygwin/etc/passwd</filename>, or by simply deleting the entire entry for your userid. If
+you do that, <command>ssh</command> uses the $HOME environment variable instead.
+</para>
+
+</listitem>
+
+<listitem>
+ <para>To protect your
+ <literal>.ssh</literal> from access by anyone else,
+ right-click your <literal>.ssh</literal> directory, and
+ select <literal>Properties</literal>. 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!</para>
+</listitem>
+
+<listitem>
+ <para>In fact <command>ssh</command> 3.6.1 now seems to <emphasis>require</emphasis>
+ you to have Unix permissions 600 (read/write for owner only)
+ on the <literal>.ssh/identity</literal> file, else it
+ bombs out. For your local C drive, it seems that <literal>chmod 600 identity</literal> 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 "<literal>ntsec neta</literal>". The $CYGWIN environment variable is discussed
+ in <ulink url="http://cygwin.com/cygwin-ug-net/using-cygwinenv.html">the Cygwin User's Guide</ulink>,
+ and there are more details in <ulink url="http://cygwin.com/faq/faq_4.html#SEC44">the Cygwin FAQ</ulink>.
+ </para>
+</listitem>
+</itemizedlist>
+</para>
+</sect2>
+
<Sect2><Title>Other things you need to install</Title>
<para>You have to install the following other things to build GHC:
(see <xref linkend="ghc-mingw">). </para>
<para> 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 <command>gcc</command>, not a cygwin path, because GHC (which
-uses this path to invoke <command>gcc</command>) is a Mingw program and won't
-understand a cygwin path.. For example, if you
+trouble using the wrong C compiler!</para>
+<para>
+Furthermore, it's <emphasis>very important</emphasis> that you specify a
+full MinGW path for <command>gcc</command>, not a Cygwin path, because GHC (which
+uses this path to invoke <command>gcc</command>) is a MinGW program and won't
+understand a Cygwin path. For example, if you
say <literal>--with-gcc=/mingw/bin/gcc</literal>, it'll be interpreted as
<filename>/cygdrive/c/mingw/bin/gcc</filename>, and GHC will fail the first
-time it tries to invoke it. (Worse, the failure does not come with
-a helpful error message, unfortunately.)
+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:
+<programlisting>
+make[4]: 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[2]: *** [Adjustor.o] Error 1
+make[1]: *** [all] Error 1
+make[1]: Leaving directory `/cygdrive/e/fptools-stage1/ghc'
+make: *** [all] Error 1
+</programlisting>
+Be warned!
</para>
<para>
</para>
</listitem>
+<listitem><para> You almost certainly want to set
+<programlisting>
+ SplitObjs = NO
+</programlisting>
+in your <filename>build.mk</filename> configuration file (see <xref linkend="sec-build-config">).
+This tells the build system not to split each library into a myriad of little object files, one
+for each function. Doing so reduces binary sizes for statically-linked binaries, but on Windows
+it dramatically increases the time taken to build the libraries in the first place.
+</para>
+</listitem>
+
<listitem><para> Do not attempt to build the documentation.
It needs all kinds of wierd Jade stuff that we haven't worked out for
Win32.</para></listitem>
projects / ghc-hetmet.git / blobdiff