% Building and installing the Glasgow Functional Programming Tools Suite
%
-% Version 2.04
-% June 1997
+% Version 2.05
+% July 1997
\begin{onlystandalone}
\documentstyle[11pt,literate]{article}
\begin{document}
\title{Building and installing the Glasgow Functional Programming Tools Suite\\
-Version~2.04}
+Version~2.05}
\author{The GHC Team\\
Department of Computing Science\\
University of Glasgow\\
Source-only distributions are either bugfix releases or snapshots of
current state of development. The release has undergone some testing.
-GHC~2.04 is a source-only release, and it can be compiled up using
-either GHC~2.02 (or the bugfix release, GHC~2.03) or the Good Old
+GHC~2.05 is a source-only release, and it can be compiled up using
+either GHC~2.02 (or subsequent bugfix releases) or the Good Old
Compiler, GHC~0.29. Compiling with 0.29 is recommended if you're
a performance junkie, as 0.29 (still) generates zippier code, but
GHC~2.04 is catching up.
%************************************************************************
%* *
-\section[port-info]{What machines the Glasgow tools, version~2.04, run on}
+\section[port-info]{What machines the Glasgow tools, version~2.05, run on}
\index{ports, GHC}
\index{GHC ports}
\index{supported platforms}
compilations. The native-code generator for iX86 platforms (e.g.,
Linux ELF) is {\em nearly} working; but is not turned on by default.
-Here's everything that's known about GHC ports, as of 2.04. We
+Here's everything that's known about GHC ports, as of 2.05. We
identify platforms by their ``canonical'' CPU/Manufacturer/OS triple.
Note that some ports are fussy about which GCC version you use; or
%-------------------------------------------------------------------
\item[\tr{i386-*-linux} (PCs running Linux---ELF format):]
\index{i386-*-linux: registerised port}
-GHC~2.04 works registerised.
+GHC~2.05 works registerised.
You {\em must} have GCC 2.7.x or later.
The iX86 native-code generator is {\em nearly} there, but it
isn't turned on by default.
%-------------------------------------------------------------------
\item[\tr{i386-*-freebsd} (PCs running FreeBSD 2.2 or higher, and
NetBSD/OpenBSD using FreeBSD emulation):] \index{i386-*-freebsd:
-registerised port} GHC~2.04 works registerised. Supports same set of
+registerised port} GHC~2.05 works registerised. Supports same set of
bundles as the above.
\index{i386-*-freebsd: profiling---yes}
%-------------------------------------------------------------------
\item[\tr{mips-sgi-irix5}:]
\index{mips-sgi-irix5: registerised port}
-GHC~2.04 works registerised (no native-code generator).
+GHC~2.05 works registerised (no native-code generator).
I suspect any GCC~2.6.x (or later) is OK. The GCC that I used
was built with \tr{--with-gnu-as}; turns out that is important!
\item[\tr{mips-sgi-irix6}:]
\index{mips-sgi-irix6: registerised port}
Thanks to the fine efforts of Tomasz Cholewo
-\tr{<tjchol01@mecca.spd.louisville.edu>}, GHC~2.04 works registerised
+\tr{<tjchol01@mecca.spd.louisville.edu>}, GHC~2.05 works registerised
(no native code generator) under IRIX 6.2 and 6.3. Depends on having
specially tweaked version of gcc-2.7.2 around, which can be downloaded
from
%-------------------------------------------------------------------
\item[\tr{powerpc-ibm-aix}:]
\index{powerpc-ibm-aix: registerised port}
-GHC~2.04 works registerised (no native-code generator..yet).
+GHC~2.05 works registerised (no native-code generator..yet).
I suspect 2.7.x is what you need together with this.
Concurrent/Parallel Haskell probably don't work (yet).
%-------------------------------------------------------------------
\item[\tr{m68k-sun-sunos4} (Sun3):]
\index{m68k-sun-sunos4: registerised port}
-GHC~2.04 hasn't been tried on a Sun3. GHC~0.26 worked registerised.
+GHC~2.05 hasn't been tried on a Sun3. GHC~0.26 worked registerised.
No native-code generator.
Concurrent/Parallel Haskell probably don't work (yet).
\subsection{What bundles there are}
There are plenty of ``non-basic'' GHC bundles. The files for them are
-called \tr{ghc-2.04-<bundle>-<platform>.tar.gz}, where the
+called \tr{ghc-2.05-<bundle>-<platform>.tar.gz}, where the
\tr{<platform>} is as above, and \tr{<bundle>} is one of these:
\begin{description}
\item[\tr{prof}:] Profiling with cost-centres. You probably want this.
First, give yourself a convenient way to execute the driver script
\tr{ghc/driver/ghc}, perhaps something like...
\begin{verbatim}
-% ln -s /local/src/ghc-2.04/ghc/driver/ghc ~/bin/alpha/ghc
+% ln -s /local/src/ghc-2.05/ghc/driver/ghc ~/bin/alpha/ghc
% rehash
\end{verbatim}
This is a quite-a-bit-better-than-Lex lexer. Used in the
literate-programming stuff. You won't need it unless you're hacking
on some of our more obscure stuff.
+On our machines, the version in @/bin@ doesn't work; you need the
+GNU version. Find out by saying @flex --version@ (our current version
+is 2.5.3, but maybe earlier ones will work). If it doesn't know about
+the @--version@ flag, it ain't the right @flex@.
\item[Yacc:]
\index{pre-supposed: non-worthless Yacc}
%************************************************************************
%* *
-\section{Building from source}
+\section[building-from-source]{Building from source}
+\index{Building from source}
%* *
%************************************************************************
software, and lay hands on them gently when they don't work.
\subsection{Your source tree}
+\label{source-tree}
The source code is held in your {\em source tree}.
The root directory of your source tree {\em must}
\item @mk/@: the directory that contains the
main Makefile code, shared by all the
@fptools@ software.
-\item @configure.in@: a file that tells the GNU configuration
-tools what @fptools@ needs to know about the host platform and
-operating system.
+\item @configure.in@, @config.sub@, @config.guess@:
+these files support the configuration process.
+\item @install-sh@.
\end{itemize}
All the other directories are individual {\em projects} of the
@fptools@ system --- for example, the Glasgow Haskell Compiler (@ghc@),
For example, @config.mk.in@ contains the definition:
\begin{verbatim}
- ProjectsToBuild = glafp-utils literate ghc hslibs
+ ProjectsToBuild = glafp-utils literate happy ghc hslibs
\end{verbatim}
The accompanying comment explains that this is the list of enabled
projects; that is, if (after configuring) you type @gmake all@
in @FPTOOLS_TOP@ three specified projects will be made.
-If you want to add @happy@, you can add this line to @build.mk@:
+If you want to add @green-card@, you can add this line to @build.mk@:
\begin{verbatim}
- ProjectsToBuild += happy
+ ProjectsToBuild += green-card
\end{verbatim}
or, if you prefer,
\begin{verbatim}
- ProjectsToBuild = glafp-utils literate ghc hslibs happy
+ ProjectsToBuild = glafp-utils literate happy ghc hslibs green-card
\end{verbatim}
(GNU @make@ allows existing definitions to have new text appended using
the ``@+=@'' operator, which is quite a convenient feature.)
\item Get your source tree from somewhere (CVS repository or
source distribution). Say you call the root directory
@myfptools@ (it does not have to be called @fptools@).
+Make sure that you have the essential files (see Section~\ref{source-tree}).
\item Use @lndir@ or @mkshadowdir@ to create a build tree.
\begin{verbatim}
because no binaries have been provided, or because the machine
is not ``fully supported.''
-THIS SECTION HASN'T BEEN UPDATED YET. Please let us know if you want to use this
-route. Unless someone does, this section may never get written, and the
-.hc files distribution may not get built!
+The intermediate C files are normally made available together with a
+source release, please check the announce message for exact directions
+of where to find them. If we've haven't made them available or you
+can't find them, please ask.
+
+Assuming you've got them, unpack them on top of a fresh source tree.
+Then follow the `normal' instructions in
+\sectionref{building-from-source} for setting up a build tree and
+configuring it. The only extra thing to remember when booting from
+\tr{.hc} files is to add the following line to the \tr{build.mk}
+file:
+
+\begin{verbatim}
+GhcWithHscBuiltViaC=YES
+\end{verbatim}
+
+and proceed with doing a \tr{make boot} followed by a \tr{make all}.
+
+That's the mechanics of the boot process, but, of course, if you're
+trying to boot on a platform that is not supported and significantly
+`different' from any of the supported ones, this is only the start
+of the adventure...(ToDo: porting tips - stuff to look out for, etc.)
%************************************************************************
The best way around it is to say
\begin{verbatim}
- TMPDIR=<dir>
+export TMPDIR=<dir>
\end{verbatim}
in your @build.mk@ file.
Then GHC and the other @fptools@ programs will use the appropriate directory
\item
You {\em may} need to re-\tr{ranlib} your libraries (on Sun4s).
\begin{verbatim}
-% cd $(libdir)/ghc-2.04/sparc-sun-sunos4
+% cd $(libdir)/ghc-2.05/sparc-sun-sunos4
% foreach i ( `find . -name '*.a' -print` ) # or other-shell equiv...
? ranlib $i
? # or, on some machines: ar s $i
you can do \tr{make -n whatever.dvi} to see the intended commands,
then try to muddle through, doing them by hand.
+%------------------------------------------------------------------------
+\item
+GHC's sources go through \tr{cpp}
+before being compiled, and \tr{cpp} varies a bit from one Unix to another.
+One particular gotcha is macro calls like this:
+\begin{verbatim}
+ SLIT("Hello, world")
+\end{verbatim}
+Some \tr{cpp}s treat the comma inside the string as separating two macro arguments,
+so you get
+\begin{verbatim}
+ :731: macro `SLIT' used with too many (2) args
+\end{verbatim}
+Alas, \tr{cpp} doesn't tell you the offending file!
+
+Workaround: don't put wierd things in string args to \tr{cpp} macros.
\end{enumerate}