X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fbuilding%2Fbuilding.sgml;h=ecac3764add049ba14e6ee2b770fb47fb410af05;hb=bd08f5336fd6a0982e058c2cc58ff9693db28de3;hp=565b0be5275b6715fbe433f13ef48ab8d4e70bf5;hpb=dd270783f385aa11abd05b0d7eb6cceda19bf711;p=ghc-hetmet.git diff --git a/docs/building/building.sgml b/docs/building/building.sgml index 565b0be..ecac376 100644 --- a/docs/building/building.sgml +++ b/docs/building/building.sgml @@ -1,13 +1,13 @@ -
+
- + -Building the Glasgow Functional Programming Tools Suite -The GHC Team -
glasgow-haskell-{users,bugs}@haskell.org
-November 2001 +Building the Glasgow Functional Programming Tools Suite +The GHC Team +
glasgow-haskell-{users,bugs}@haskell.org
+November 2001 The Glasgow fptools suite is a collection of Functional @@ -17,16 +17,16 @@ installation system. This guide is intended for people who want to build or - modify programs from the Glasgow fptools + modify programs from the Glasgow fptools suite (as distinct from those who merely want to - run them). Installation instructions are + run them). Installation instructions are now provided in the user guide. The bulk of this guide applies to building on Unix - systems; see for Windows notes. + systems; see for Windows notes. - + @@ -58,15 +58,13 @@ the parser specifications. If you don't want to alter the parser then this saves you having to find and install happy. You will still need a working - version of GHC (preferably version 4.08+) on your machine in + version of GHC (version 5.x or later) on your machine in order to compile (most of) the sources, however. - The CVS repository. - CVS repository - + The CVS repository.CVS repository We make releases infrequently. If you want more up-to-the minute (but less tested) source code then you need @@ -84,7 +82,7 @@ scratch. More information about our CVS repository can be found - in . + in . @@ -107,14 +105,14 @@ remember is that most mistakes can be undone, but if there's anything you're not sure about feel free to bug the local CVS meister (namely Jeff Lewis - jlewis@galconn.com). + jlewis@galois.com). Getting access to the CVS Repository You can access the repository in one of two ways: - read-only (), or read-write (). + read-only (), or read-write (). Remote Read-only CVS Access @@ -137,6 +135,12 @@ Set your $CVSROOT environment variable to :pserver:anoncvs@glass.cse.ogi.edu:/cvs + If you set $CVSROOT in a shell script, be sure not to + have any trailing spaces on that line, otherwise CVS will respond with + a perplexing message like + + /cvs : no such repository + Run the command @@ -150,7 +154,7 @@ - Now go to . + Now go to . @@ -240,40 +244,16 @@ - [Windows users.] The programs ssh-keygen1, ssh1, and cvs, - seem to lock up bash entirely if they try to get user input (e.g. if - they ask for a password). To solve this, start up cmd.exe - and run it as follows: - - c:\tmp> set CYGWIN32=tty - c:\tmp> c:/user/local/bin/ssh-keygen1 - + Windows users: see the notes in about ssh wrinkles! + + - [Windows users.] To protect your - .ssh from access by anyone else, - right-click your .ssh directory, and - select Properties. 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! - [March 2003] In fact ssh 3.6.1 now seems to require - you to have Unix permissions 600 (read/write for owner only) - on the .ssh/identity file, else it - bombs out. For your local C drive, it seems that chmod 600 identity 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 "ntsec neta". The CYGWIN environment variable is discussed - in the Cygwin User's Guide, - and there are more details in the Cygwin FAQ. - Send a message to to the CVS repository administrator (currently Jeff Lewis - jeff@galconn.com), containing: + jeff@galois.com), containing: Your desired user-name. @@ -288,7 +268,7 @@ Set the following environment variables: - + $HOME: points to your home directory. This is where CVS @@ -336,7 +316,7 @@ - + @@ -346,12 +326,12 @@ Put the following in $HOME/.cvsrc: - + checkout -P release -d update -P diff -u - + These are the default options for the specified CVS commands, @@ -421,10 +401,10 @@ some other junk. [Windows users.] The following messages appear to be harmless: - + setsockopt IPTOS_LOWDELAY: Invalid argument setsockopt IPTOS_THROUGHPUT: Invalid argument - + @@ -455,7 +435,11 @@ setsockopt IPTOS_THROUGHPUT: Invalid argument you need at least the ghc, hslibs and libraries modules (for a full list of the projects available, see - ). + ). + + Remember that if you do not have + happy and/or Alex + installed, you need to check them out as well. @@ -491,7 +475,14 @@ $ cvs diff you the results. - + + If you changed something in the + fptools/libraries subdirectories, also run + make html to check if the documentation can + be generated successfully, too. + + + Before checking in a change, you need to update your source tree: @@ -574,17 +565,25 @@ $ cvs commit -F commit-message directory major cause of headaches. So, to avoid a lot of hassle, follow this recipe for - updating your tree: + updating your tree: $ cd fptools -$ cvs update -Pd 2>&1 | tee log +$ cvs update -P 2>&1 | tee log Look at the log file, and fix any conflicts (denoted by a - C 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: + C 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 + +$ cvs update -d + in each project subdirectory. Don't do this at the top level, + because then all the projects will be + checked out. + + 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: $ cd build-tree @@ -725,9 +724,23 @@ $ cvs checkout nofib/spectral - ghc - ghc - project + + alex + alexproject + + + The Alex lexical + analyser generator for Haskell. + + + + + + ghc + ghc + project + The Glasgow Haskell Compiler (minus libraries). Absolutely @@ -736,8 +749,10 @@ $ cvs checkout nofib/spectral - glafp-utils - glafp-utilsproject + + glafp-utils + glafp-utilsproject + Utility programs, some of which are used by the build/installation system. Required for pretty much @@ -746,19 +761,23 @@ $ cvs checkout nofib/spectral - green-card - green-cardproject + + greencard + greencardproject + The Green Card + url="http://www.haskell.org/greencard/">GreenCard system for generating Haskell foreign function interfaces. - haggis - haggisproject + + haggis + haggisproject + The Haggis @@ -767,8 +786,10 @@ $ cvs checkout nofib/spectral - haddock - haddockproject + + haddock + haddockproject + The Haddock @@ -777,8 +798,10 @@ $ cvs checkout nofib/spectral - happy - happyproject + + happy + happyproject + The Happy Parser @@ -787,8 +810,10 @@ $ cvs checkout nofib/spectral - hdirect - hdirectproject + + hdirect + hdirectproject + The H/Direct @@ -797,8 +822,10 @@ $ cvs checkout nofib/spectral - hood - hoodproject + + hood + hoodproject + The Haskell Object Observation Debugger. @@ -806,8 +833,10 @@ $ cvs checkout nofib/spectral - hslibs - hslibsproject + + hslibs + hslibsproject + Supplemental libraries for GHC (required for building GHC). @@ -815,8 +844,10 @@ $ cvs checkout nofib/spectral - libraries - project + + libraries + project + Hierarchical Haskell library suite (required for building GHC). @@ -824,16 +855,20 @@ $ cvs checkout nofib/spectral - mhms - project + + mhms + project + The Modular Haskell Metric System. - nofib - nofibproject + + nofib + nofibproject + The NoFib suite: A collection of Haskell programs used primarily for benchmarking. @@ -841,8 +876,10 @@ $ cvs checkout nofib/spectral - testsuite - testsuiteproject + + testsuite + testsuiteproject + A testing framework, including GHC's regression test suite. @@ -864,9 +901,8 @@ $ cvs checkout nofib/spectral - - Disk space needed - Disk space needed: from about 100Mb for a basic GHC + Disk space neededDisk + space needed: from about 100Mb for a basic GHC build, up to probably 500Mb for a GHC build with everything included (libraries built several different ways, etc.). @@ -874,23 +910,23 @@ $ cvs checkout nofib/spectral Use an appropriate machine / operating system. lists the supported platforms; if + linkend="sec-port-info"/> lists the supported platforms; if yours isn't amongst these then you can try porting GHC (see - ). + ). Be sure that the “pre-supposed” utilities are - installed. + installed. elaborates. If you have any problem when building or installing the - Glasgow tools, please check the “known pitfalls” (). Also check the FAQ for the + Glasgow tools, please check the “known pitfalls” (). Also check the FAQ for the version you're building, which is part of the User's Guide and - available on the GHC web + available on the GHC web site. bugsknown @@ -966,13 +1002,13 @@ $ cvs checkout nofib/spectral - alpha-dec-{osf,linux,freebsd,openbsd,netbsd}: + alpha-dec-{osf,linux,freebsd,openbsd,netbsd}: alpha-dec-osf alpha-dec-linux alpha-dec-freebsd alpha-dec-openbsd alpha-dec-netbsd - + The OSF port is currently working (as of GHC version 5.02.1) and well supported. The native code generator is @@ -982,8 +1018,9 @@ $ cvs checkout nofib/spectral - sparc-sun-sunos4 - sparc-sun-sunos4 + sparc-sun-sunos4 + sparc-sun-sunos4 + Probably works with minor tweaks, hasn't been tested for a while. @@ -991,17 +1028,29 @@ $ cvs checkout nofib/spectral - sparc-sun-solaris2 - sparc-sun-solaris2 + sparc-sun-solaris2 + sparc-sun-solaris2 + - Fully supported (at least for Solaris 2.7), + Fully supported (at least for Solaris 2.7 and 2.6), including native-code generator. - hppa1.1-hp-hpux (HP-PA boxes running HPUX 9.x) - hppa1.1-hp-hpux + sparc-unknown-openbsd + sparc-unknown-openbsd + + + Supported, including native-code generator. The + same should also be true of NetBSD + + + + + hppa1.1-hp-hpux (HP-PA boxes running HPUX 9.x) + hppa1.1-hp-hpux + A registerised port is available for version 4.08, but GHC hasn't been built on that platform since (as far @@ -1010,11 +1059,12 @@ $ cvs checkout nofib/spectral - i386-unknown-linux (PCs running Linux, ELF binary format) - i386-*-linux + i386-unknown-linux (PCs running Linux, ELF binary format) + i386-*-linux + GHC works registerised and has a native code - generator. You must have GCC 2.7.x + generator. You must have GCC 2.7.x or later. NOTE about glibc versions: GHC binaries built on a system running glibc 2.0 won't work on a system running @@ -1026,9 +1076,9 @@ $ cvs checkout nofib/spectral - i386-unknown-freebsd (PCs running FreeBSD 2.2 or - higher) - i386-unknown-freebsd + i386-unknown-freebsd (PCs running FreeBSD 2.2 or higher) + i386-unknown-freebsd + GHC works registerised. Pre-built packages are available in the native package format, so if you just @@ -1039,8 +1089,9 @@ $ cvs checkout nofib/spectral - i386-unknown-openbsd (PCs running OpenBSD) - i386-unknown-openbsd + i386-unknown-openbsd (PCs running OpenBSD) + i386-unknown-openbsd + Supported, with native code generator. Packages are available through the ports system in the native package @@ -1049,9 +1100,9 @@ $ cvs checkout nofib/spectral - i386-unknown-netbsd (PCs running NetBSD and - OpenBSD) - i386-unknown-netbsd + i386-unknown-netbsd (PCs running NetBSD) + i386-unknown-netbsd + Will require some minor porting effort, but should work registerised. @@ -1059,8 +1110,9 @@ $ cvs checkout nofib/spectral - i386-unknown-mingw32 (PCs running Windows) - i386-unknown-mingw32 + i386-unknown-mingw32 (PCs running Windows) + i386-unknown-mingw32 + Fully supported under Win9x, WinNT, Win2k, and WinXP. Includes a native code generator. Building from @@ -1071,8 +1123,19 @@ $ cvs checkout nofib/spectral - ia64-unknown-linux - ia64-unknown-linux + ia64-unknown-linux + ia64-unknown-linux + + + Supported, except there is no native code + generator. + + + + + x86_64-unknown-linux + x86_64-unknown-linux + GHC currently works unregisterised. A registerised port is in progress. @@ -1080,8 +1143,20 @@ $ cvs checkout nofib/spectral - mips-sgi-irix5 - mips-sgi-irix[5-6] + amd64-unknown-openbsd + amd64-unknown-linux + + + (This is the same as x86_64-unknown-openbsd). GHC + currently works unregisterised. A registerised port is in + progress. + + + + + mips-sgi-irix5 + mips-sgi-irix[5-6] + Port has worked in the past, but hasn't been tested for some time (and will certainly have rotted in various @@ -1092,8 +1167,18 @@ $ cvs checkout nofib/spectral - powerpc-ibm-aix - powerpc-ibm-aix + mips64-sgi-irix6 + mips-sgi-irix6 + + + GHC currently works unregisterised. + + + + + powerpc-ibm-aix + powerpc-ibm-aix + Port currently doesn't work, needs some minimal porting effort. As usual, we don't have access to @@ -1103,17 +1188,19 @@ $ cvs checkout nofib/spectral - powerpc-apple-darwin - powerpc-apple-darwin + powerpc-apple-darwin + powerpc-apple-darwin + - Supported registerised. No native code - generator. + Supported registerised. Native code generator is + almost working. - powerpc-apple-linux - powerpc-apple-linux + powerpc-apple-linux + powerpc-apple-linux + Not supported (yet). @@ -1152,14 +1239,15 @@ $ cvs checkout nofib/spectral - GHC - pre-supposed: GHC - GHC, pre-supposed + GHC + pre-supposed: GHC + GHC, pre-supposed + GHC is required to build many of the tools, including GHC itself. If you need to port GHC to your platform because there isn't a binary distribution of GHC available, - then see . + then see . Which version of GHC you need will depend on the packages you intend to build. GHC itself will normally @@ -1169,9 +1257,10 @@ $ cvs checkout nofib/spectral - Perl - pre-supposed: Perl - Perl, pre-supposed + Perl + pre-supposed: Perl + Perl, pre-supposed + You have to have Perl to proceed! Perl version 5 at least is required. GHC has been known to @@ -1193,10 +1282,10 @@ $ cvs checkout nofib/spectral - GNU C (gcc) - pre-supposed: GCC (GNU C - compiler) GCC (GNU C - compiler), pre-supposed + GNU C (gcc) + pre-supposed: GCC (GNU C compiler) + GCC (GNU C compiler), pre-supposed + We recommend using GCC version 2.95.2 on all platforms. Failing that, version 2.7.2 is stable on most @@ -1205,9 +1294,12 @@ $ cvs checkout nofib/spectral egcs) have varying degrees of stability depending on the platform. + GCC 3.2 is currently known to have problems building + GHC on Sparc, but is stable on x86. + 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 + it and get things improved. (Exception: on x86 boxes—you may need to fiddle with GHC's option; see the User's Guide) @@ -1215,9 +1307,9 @@ $ cvs checkout nofib/spectral - GNU Make - makeGNU - + GNU Make + makeGNU + The fptools build system makes heavy use of features specific to GNU make, so you must have @@ -1227,8 +1319,9 @@ $ cvs checkout nofib/spectral - Happy - Happy + Happy + Happy + Happy is a parser generator tool for Haskell, and is used to generate GHC's parsers. Happy is written in @@ -1236,7 +1329,7 @@ $ cvs checkout nofib/spectral (fptools/happy). 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 Happy's Web Page. @@ -1244,26 +1337,47 @@ $ cvs checkout nofib/spectral - Autoconf - pre-supposed: Autoconf - Autoconf, pre-supposed + Alex + Alex + - GNU Autoconf is needed if you intend to build from the + Alex is a lexical-analyser generator for Haskell, + which GHC uses to generate its lexer. Like Happy, Alex is + written in Haskell and is a project in the CVS repository. + Alex distributions are available from Alex's Web + Page. + + + + + autoconf + pre-supposed: autoconf + autoconf, pre-supposed + + + GNU autoconf is needed if you intend to build from the CVS sources, it is not needed if you just intend to build a standard source distribution. - Autoconf builds the configure - script from configure.in and - aclocal.m4. If you modify either of - these files, you'll need autoconf to - rebuild configure. + Version 2.52 or later of the autoconf package is required. + NB. version 2.13 will no longer work, as of GHC version + 6.1. + + autoreconf (from the autoconf package) + recursively builds configure scripts from + the corresponding configure.ac and + aclocal.m4 files. If you modify one of + the latter files, you'll need autoreconf to + rebuild the corresponding configure. - sed - pre-supposed: sed - sed, pre-supposed + sed + pre-supposed: sed + sed, pre-supposed + You need a working sed if you are going to build from sources. The build-configuration stuff @@ -1287,13 +1401,14 @@ $ cvs checkout nofib/spectral - PVM version 3: + PVM version 3: pre-supposed: PVM3 (Parallel Virtual Machine) - PVM3 (Parallel Virtual Machine), pre-supposed + PVM3 (Parallel Virtual Machine), pre-supposed + 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 @@ -1311,8 +1426,9 @@ $ cvs checkout nofib/spectral - bash: - bash, presupposed (Parallel Haskell only) + bash: + bash, presupposed (Parallel Haskell only) + Sadly, the gr2ps script, used to convert “parallelism profiles” to PostScript, @@ -1328,9 +1444,10 @@ $ cvs checkout nofib/spectral - Flex - pre-supposed: flex - flex, pre-supposed + Flex + pre-supposed: flex + flex, pre-supposed + This is a quite-a-bit-better-than-Lex lexer. Used to build a couple of utilities in @@ -1343,7 +1460,7 @@ $ cvs checkout nofib/spectral More tools are required if you want to format the documentation that comes with GHC and other fptools projects. See . + linkend="building-docs"/>. @@ -1376,7 +1493,8 @@ $ cvs checkout nofib/spectral want a completely standard build, then the following should work: -$ ./configure +$ autoreconf +$ ./configure $ make $ make install @@ -1410,7 +1528,7 @@ $ make install - configure.in, + configure.ac, config.sub, config.guess: these files support the configuration process. @@ -1433,7 +1551,7 @@ $ make install only one project (happy, say), you must have a source tree whose root directory contains Makefile, mk/, - configure.in, and the project(s) you want + configure.ac, and the project(s) you want (happy/ in this case). You cannot get by with just the happy/ directory. @@ -1464,8 +1582,8 @@ $ make install are two (If you don't have either, the source distribution includes sources for the X11 lndir—check out - fptools/glafp-utils/lndir). See for a typical invocation. + fptools/glafp-utils/lndir). See for a typical invocation. The build tree does not need to be anywhere near the source tree in the file system. Indeed, one advantage of @@ -1473,8 +1591,8 @@ $ make install can be placed in a non-backed-up partition, saving your systems support people from backing up untold megabytes of easily-regenerated, and rapidly-changing, gubbins. The golden - rule is that (with a single exception—) absolutely everything in + rule is that (with a single exception—) absolutely everything in the build tree is either a symbolic link to the source tree, or else is mechanically generated. It should be perfectly OK for your build tree to vanish overnight; an hour or @@ -1509,7 +1627,7 @@ $ make install $(FPTOOLS_TOP) unless otherwise stated. For example, the file ghc/mk/target.mk is actually - $(FPTOOLS_TOP)/ghc/mk/target.mk. + $(FPTOOLS_TOP)/ghc/mk/target.mk. @@ -1547,26 +1665,32 @@ $ make install Change directory to $(FPTOOLS_TOP) and - issue the command - autoconfautoconf - (with no arguments). This GNU program converts - $(FPTOOLS_TOP)/configure.in + issue the command + +autoreconf + + autoreconf + (with no arguments). This GNU program (recursively) converts + $(FPTOOLS_TOP)/configure.ac and + $(FPTOOLS_TOP)/aclocal.m4 to a shell script called - $(FPTOOLS_TOP)/configure. + $(FPTOOLS_TOP)/configure. + If autoreconf bleats that it can't write the file configure, + then delete the latter and try again. Note that you must use autoreconf, + and not the old autoconf! If you erroneously use the latter, you'll get + a message like "No rule to make target 'mk/config.h.in'". - Some projects, including GHC, have their own - configure script. If there's an - $(FPTOOLS_TOP)/<project>/configure.in, - then you need to run autoconf in that - directory too. - - Both these steps are completely - platform-independent; they just mean that the - human-written file (configure.in) can - be short, although the resulting shell script, - configure, and - mk/config.h.in, are long. + Some projects, including GHC, have their own configure script. + autoreconf takes care of that, too, so all you have + to do is calling autoreconf in the top-level directory + $(FPTOOLS_TOP). + + These steps are completely platform-independent; they just mean + that the human-written files (configure.ac and + aclocal.m4) can be short, although the resulting + files (the configure shell scripts and the C header + template mk/config.h.in) are long. @@ -1576,15 +1700,15 @@ $ make install Runs the newly-created configure script, thus: - + ./configure args - + configure's mission is to scurry round your computer working out what architecture it has, what operating system, whether it has the - vfork system call, where - yacc is kept, whether + vfork system call, where + tar is kept, whether gcc is available, where various obscure #include files are, whether it's a leap year, and what the systems manager had for lunch. It @@ -1628,9 +1752,9 @@ $ make install - --with-ghc=path - --with-ghc - + --with-ghc=path + --with-ghc + Specifies the path to an installed GHC which you would like to use. This compiler will be used @@ -1645,9 +1769,9 @@ $ make install - --with-hc=path - --with-hc - + --with-hc=path + --with-hc + Specifies the path to any installed Haskell compiler. This compiler will be used for compiling @@ -1657,9 +1781,9 @@ $ make install - --with-gcc=path - --with-gcc - + --with-gcc=path + --with-gcc + Specifies the path to the installed GCC. This compiler will be used to compile all C files, @@ -1670,13 +1794,6 @@ $ make install - - configure caches the results of - its run in config.cache. Quite often - you don't want that; you're running - configure a second time because - something has changed. In that case, simply delete - config.cache. @@ -1721,12 +1838,15 @@ $ make install includes build.mk after config.mk.) + For your convenience, there's a file called build.mk.sample + that can serve as a starting point for your build.mk. + For example, config.mk.in contains the definition: - + GhcHcOpts=-O -Rghc-timing - + The accompanying comment explains that this is the list of flags passed to GHC when building GHC itself. For doing @@ -1736,9 +1856,9 @@ GhcHcOpts=-O -Rghc-timing or, if you prefer, - + GhcHcOpts += -DDEBUG - + GNU make allows existing definitions to have new text appended using the “+=” @@ -1749,9 +1869,9 @@ GhcHcOpts += -DDEBUG lot quicker), you can just override GhcLibHcOpts altogether: - + GhcHcOpts=-DDEBUG -Rghc-timing - + When reading config.mk.in, remember that anything between “@...@” signs is going to be substituted @@ -1760,19 +1880,19 @@ GhcHcOpts=-DDEBUG -Rghc-timing you want, but you need to be a bit surer what you are doing. For example, there's a line that says: - -YACC = @YaccCmd@ - + +TAR = @TarCmd@ + - This defines the Make variables YACC - to the pathname for a yacc that + This defines the Make variables TAR + to the pathname for a tar that configure finds somewhere. If you have your - own pet yacc you want to use instead, that's + own pet tar you want to use instead, that's fine. Just add this line to mk/build.mk: - -YACC = myyacc - + +TAR = mytar + You do not have to have a mk/build.mk file at all; if you don't, @@ -1803,8 +1923,8 @@ YACC = myyacc 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 ). + have the essential files (see ). @@ -1838,21 +1958,13 @@ $ cd /scratch/joe-bloggs/myfptools-sun4 Prepare for system configuration: -$ autoconf +$ autoreconf (You can skip this step if you are starting from a source distribution, and you already have configure and mk/config.h.in.) - - Some projects, including GHC itself, have their own - configure scripts, so it is necessary to run autoconf again - in the appropriate subdirectories. eg: - - -$ (cd ghc; autoconf) - @@ -2144,8 +2256,8 @@ $ emacs mk/build.mk is only available in the root directory $(FPTOOLS_TOP); it has - been discussed in . + been discussed in . @@ -2161,9 +2273,9 @@ $ emacs mk/build.mk generated .depend file will contain the dependency: - + Foo.o : Baz.hi - + which says that the object file Foo.o depends on the interface file @@ -2207,13 +2319,14 @@ Foo.o : Baz.hi Do NOT use ghc/compiler/ghc, or - ghc/compiler/ghc-5.xx, as these are the + ghc/compiler/ghc-6.xx, 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. Happy can similarly be run from the build tree, using - happy/src/happy-inplace. + happy/src/happy-inplace, and similarly for + Alex and Haddock. @@ -2229,9 +2342,9 @@ Foo.o : Baz.hi make is going to rebuild everything anyway, the following hack may be useful: - + gmake FAST=YES - + This tells the make system to ignore dependencies and just build what you tell it to. In other words, it's equivalent to @@ -2300,7 +2413,7 @@ gmake FAST=YES Makefile, minimal - + # Makefile for fptools project "small" TOP = .. @@ -2310,7 +2423,7 @@ SRCS = $(wildcard *.lhs) $(wildcard *.c) HS_PROG = small include $(TOP)/target.mk - + this Makefile has three sections: @@ -2329,11 +2442,11 @@ directive. a file of “boilerplate” code from the level above (which in this case will be - FPTOOLS_TOP/mk/boilerplate.mkboilerplate.mk). + FPTOOLS_TOP/mk/boilerplate.mkboilerplate.mk). As its name suggests, boilerplate.mk consists of a large quantity of standard Makefile code. We discuss this - boilerplate in more detail in . + boilerplate in more detail in . include, directive in Makefiles Makefile inclusion @@ -2345,9 +2458,9 @@ directive. directory in which the boilerplate.mk file is. It is not OK to simply say - + include ../mk/boilerplate.mk # NO NO NO - + Why? Because the boilerplate.mk @@ -2360,7 +2473,7 @@ include ../mk/boilerplate.mk # NO NO NO included sits.) In general, every file foo.mk assumes that - $(TOP)/mk/foo.mk + $(TOP)/mk/foo.mk refers to itself. It is up to the Makefile doing the include to ensure this is the case. @@ -2385,8 +2498,8 @@ include ../mk/boilerplate.mk # NO NO NO HS_PROGHS_PROG (the executable binary to be built). We will discuss in more detail what the “standard variables” are, - and how they affect what happens, in . + and how they affect what happens, in . The definition for SRCS uses the useful GNU make construct @@ -2405,12 +2518,12 @@ include ../mk/boilerplate.mk # NO NO NO code, called target.mktarget.mk. It contains the rules that tell gmake how - to make the standard targets (). Why, you ask, can't this + to make the standard targets (). Why, you ask, can't this standard code be part of boilerplate.mk? Good question. We - discuss the reason later, in . + discuss the reason later, in . You do not have to include the @@ -2419,8 +2532,8 @@ include ../mk/boilerplate.mk # NO NO NO though, you will find quite a big payoff from using the canned rules in target.mk; the price tag is that you have to understand what canned rules get - enabled, and what they do (). + enabled, and what they do (). @@ -2476,7 +2589,7 @@ include ../mk/boilerplate.mk # NO NO NO rare.) To give you the idea, here's part of the directory structure for the (rather large) GHC project: - + $(FPTOOLS_TOP)/ghc/ Makefile mk/ @@ -2493,14 +2606,14 @@ $(FPTOOLS_TOP)/ghc/ parser/...source files for parser... renamer/...source files for renamer... ...etc... - + The sub-directories docs, driver, compiler, and so on, each contains a sub-component of GHC, and each has its own Makefile. There must also be a Makefile in - $(FPTOOLS_TOP)/ghc. + $(FPTOOLS_TOP)/ghc. It does most of its work by recursively invoking gmake on the Makefiles in the sub-directories. We say that @@ -2602,9 +2715,9 @@ $(FPTOOLS_TOP)/ghc/ augment them. For example, a Makefile might say: - + SRC_HC_OPTS += -O - + thereby adding “” to the end of @@ -2614,7 +2727,7 @@ SRC_HC_OPTS += -O target.mk contains make rules for the standard targets - described in . These + described in . These rules are selectively included, depending on the setting of certain make variables. These variables are usually set in the middle section of the @@ -2631,13 +2744,13 @@ SRC_HC_OPTS += -O gmake commits target and dependency lists earlier than it should. For example, - target.mk has a rule that looks + target.mk has a rule that looks like this: - + $(HS_PROG) : $(OBJS) $(HC) $(LD_OPTS) $< -o $@ - + If this rule was in boilerplate.mk then @@ -2678,23 +2791,25 @@ $(HS_PROG) : $(OBJS) boilerplate.mk If you look at - $(FPTOOLS_TOP)/mk/boilerplate.mk + $(FPTOOLS_TOP)/mk/boilerplate.mk you will find that it consists of the following sections, each held in a separate file: - config.mk - config.mk + config.mk + config.mk + is the build configuration file we discussed at - length in . + length in . - paths.mk - paths.mk + paths.mk + paths.mk + defines make variables for pathnames and file lists. This file contains code for @@ -2710,9 +2825,9 @@ $(HS_PROG) : $(OBJS) - ALL_DIRS - ALL_DIRS - + ALL_DIRS + ALL_DIRS + Set to a list of directories to search in addition to the current directory for source @@ -2721,9 +2836,9 @@ $(HS_PROG) : $(OBJS) - EXCLUDE_SRCS - EXCLUDE_SRCS - + EXCLUDE_SRCS + EXCLUDE_SRCS + Set to a list of source files (relative to the current directory) to omit from the automatic @@ -2739,9 +2854,9 @@ $(HS_PROG) : $(OBJS) - EXTRA_SRCS - EXCLUDE_SRCS - + EXTRA_SRCS + EXCLUDE_SRCS + Set to a list of extra source files (perhaps in directories not listed in @@ -2756,8 +2871,9 @@ $(HS_PROG) : $(OBJS) - SRCS - SRCS + SRCS + SRCS + All source files found, sorted and without duplicates, including those which might not exist @@ -2769,8 +2885,9 @@ $(HS_PROG) : $(OBJS) - HS_SRCS - HS_SRCS + HS_SRCS + HS_SRCS + all Haskell source files in the current directory, including those derived from other source @@ -2780,8 +2897,9 @@ $(HS_PROG) : $(OBJS) - HS_OBJS - HS_OBJS + HS_OBJS + HS_OBJS + Object files derived from HS_SRCS. @@ -2789,8 +2907,9 @@ $(HS_PROG) : $(OBJS) - HS_IFACES - HS_IFACES + HS_IFACES + HS_IFACES + Interface files (.hi files) derived from HS_SRCS. @@ -2798,16 +2917,18 @@ $(HS_PROG) : $(OBJS) - C_SRCS + C_SRCS C_SRCS + All C source files found. - C_OBJS + C_OBJS C_OBJS + Object files derived from C_SRCS. @@ -2815,8 +2936,9 @@ $(HS_PROG) : $(OBJS) - SCRIPT_SRCS + SCRIPT_SRCS SCRIPT_SRCS + All script source files found (.lprl files). @@ -2824,8 +2946,9 @@ $(HS_PROG) : $(OBJS) - SCRIPT_OBJS + SCRIPT_OBJS SCRIPT_OBJS + object files derived from SCRIPT_SRCS @@ -2834,8 +2957,9 @@ $(HS_PROG) : $(OBJS) - HSC_SRCS + HSC_SRCS HSC_SRCS + All hsc2hs source files (.hsc files). @@ -2843,8 +2967,9 @@ $(HS_PROG) : $(OBJS) - HAPPY_SRCS + HAPPY_SRCS HAPPY_SRCS + All happy source files (.y or .hy files). @@ -2852,8 +2977,9 @@ $(HS_PROG) : $(OBJS) - OBJS + OBJS OBJS + the concatenation of $(HS_OBJS), @@ -2879,23 +3005,25 @@ $(HS_PROG) : $(OBJS) - opts.mk - opts.mk + opts.mk + opts.mk + defines make variables for option strings to pass to each program. For example, it defines HC_OPTSHC_OPTS, the option strings to pass to the Haskell compiler. See - . + . - suffix.mk - suffix.mk + suffix.mk + suffix.mk + - defines standard pattern rules—see . + defines standard pattern rules—see . @@ -2924,11 +3052,11 @@ $(HS_PROG) : $(OBJS) Almost all the rules look something like this: - + %.o : %.c $(RM) $@ $(CC) $(CC_OPTS) -c $< -o $@ - + Here's how to understand the rule. It says that something.o (say @@ -2956,9 +3084,10 @@ $(HS_PROG) : $(OBJS) defined in mk/opts.mk. Almost all of them are defined like this: - -CC_OPTS = $(SRC_CC_OPTS) $(WAY$(_way)_CC_OPTS) $($*_CC_OPTS) $(EXTRA_CC_OPTS) - + +CC_OPTS = \ + $(SRC_CC_OPTS) $(WAY$(_way)_CC_OPTS) $($*_CC_OPTS) $(EXTRA_CC_OPTS) + The four variables from which CC_OPTS is built have the following @@ -2982,7 +3111,7 @@ CC_OPTS = $(SRC_CC_OPTS) $(WAY$(_way)_CC_OPTS) $($*_CC_OPTS) $(EXTRA_CC_OPTS) mp. The variable WAY_CC_OPTS holds options to pass to the C compiler when compiling the - standard way. ( dicusses + standard way. ( dicusses multi-way compilation.) @@ -3004,9 +3133,9 @@ CC_OPTS = $(SRC_CC_OPTS) $(WAY$(_way)_CC_OPTS) $($*_CC_OPTS) $(EXTRA_CC_OPTS) extra options to pass to all C compilations. This is intended for command line use, thus: - + gmake libHS.a EXTRA_CC_OPTS="-v" - + @@ -3017,8 +3146,8 @@ gmake libHS.a EXTRA_CC_OPTS="-v" target.mk target.mk contains canned rules for - all the standard targets described in . It is complicated by the fact + all the standard targets described in . It is complicated by the fact that you don't want all of these rules to be active in every Makefile. Rather than have a plethora of tiny files which you can include selectively, there is a single @@ -3112,10 +3241,10 @@ gmake libHS.a EXTRA_CC_OPTS="-v" All of these rules are “double-colon” rules, thus - + install :: $(HS_PROG) ...how to install it... - + GNU make treats double-colon rules as separate entities. If there are several double-colon rules for @@ -3146,7 +3275,7 @@ install :: $(HS_PROG) When SUBDIRS is defined, target.mk includes a rather neat rule for - the standard targets ( that + the standard targets ( that simply invokes make recursively in each of the sub-directories. @@ -3235,8 +3364,8 @@ install :: $(HS_PROG) Makefile to the list of way tags you want these targets built for. The mechanism here is very much like the recursive invocation of - make in sub-directories (). It is up to you to set + make in sub-directories (). It is up to you to set WAYS in your Makefile; this is how you control what ways will get built. @@ -3256,10 +3385,10 @@ install :: $(HS_PROG) file will match. The key pattern rules (in suffix.mk) look like this: - + %.$(way_)o : %.lhs $(HC) $(HC_OPTS) $< -o $@ - + Neat, eh? @@ -3307,9 +3436,10 @@ $ make way=p - DocBook - pre-supposed: DocBook - DocBook, pre-supposed + DocBook + pre-supposed: DocBook + DocBook, pre-supposed + Much of our documentation is written in SGML, using the DocBook DTD. Instructions on installing and @@ -3318,9 +3448,10 @@ $ make way=p - TeX - pre-supposed: TeX - TeX, pre-supposed + TeX + pre-supposed: TeX + TeX, pre-supposed + A decent TeX distribution is required if you want to produce printable documentation. We recomment teTeX, @@ -3329,9 +3460,9 @@ $ make way=p - Haddock - Haddock - + Haddock + Haddock + Haddock is a Haskell documentation tool that we use for automatically generating documentation from the @@ -3358,21 +3489,21 @@ $ make way=p If you don't have DocBook tools installed, and you are using a system that can handle RedHat RPM packages, you can - probably use the Cygnus - DocBook tools, which is the most shrink-wrapped SGML + probably use the Cygnus + DocBook tools, which is the most shrink-wrapped SGML suite that we could find. You need all the RPMs except for - psgml (i.e. docbook, - jade, jadetex, - sgmlcommon and - stylesheets). Note that most of these + psgml (i.e. docbook, + jade, jadetex, + sgmlcommon and + stylesheets). Note that most of these RPMs are architecture neutral, so are likely to be found in a - noarch directory. The SuSE RPMs also - work; the RedHat ones don't in RedHat 6.2 + noarch directory. The SuSE RPMs also + work; the RedHat ones don't in RedHat 6.2 (7.0 and later should be OK), but they are easy to fix: just make a symlink from - /usr/lib/sgml/stylesheets/nwalsh-modular/lib/dblib.dsl - to /usr/lib/sgml/lib/dblib.dsl. + /usr/lib/sgml/stylesheets/nwalsh-modular/lib/dblib.dsl + to /usr/lib/sgml/lib/dblib.dsl. @@ -3396,17 +3527,17 @@ $ make way=p Installing from binaries on Windows - It's a good idea to use Norman Walsh's installation - notes as a guide. You should get version 3.1 of - DocBook, and note that his file test.sgm + It's a good idea to use Norman Walsh's installation + notes as a guide. You should get version 3.1 of + DocBook, and note that his file test.sgm won't work, as it needs version 3.0. You should unpack Jade - into \Jade, along with the entities, - DocBook into \docbook, and the DocBook - stylesheets into \docbook\stylesheets (so + into \Jade, along with the entities, + DocBook into \docbook, and the DocBook + stylesheets into \docbook\stylesheets (so they actually end up in - \docbook\stylesheets\docbook). - + \docbook\stylesheets\docbook). + @@ -3415,58 +3546,58 @@ $ make way=p Jade - Install OpenJade + Install OpenJade (Windows binaries are available as well as sources). If you want DVI, PS, or PDF then install JadeTeX from the - dsssl subdirectory. (If you get the + dsssl subdirectory. (If you get the error: ! LaTeX Error: Unknown option implicit=false' for package hyperref'. - your version of hyperref is out of date; + your version of hyperref is out of date; download it from CTAN - (macros/latex/contrib/supported/hyperref), + (macros/latex/contrib/supported/hyperref), and make it, ensuring that you have first removed or renamed your old copy. If you start getting file not found errors - when making the test for hyperref, you + when making the test for hyperref, you can abort at that point and proceed straight to - make install, or enter them as - ../filename.) + make install, or enter them as + ../filename.) - Make links from virtex to - jadetex and - pdfvirtex to - pdfjadetex (otherwise DVI, PostScript + Make links from virtex to + jadetex and + pdfvirtex to + pdfjadetex (otherwise DVI, PostScript and PDF output will not work). Copy - dsssl/*.{dtd,dsl} and - catalog to - /usr/[local/]lib/sgml. + dsssl/*.{dtd,dsl} and + catalog to + /usr/[local/]lib/sgml. DocBook and the DocBook stylesheets - Get a Zip of DocBook + Get a Zip of DocBook and install the contents in - /usr/[local/]/lib/sgml. + /usr/[local/]/lib/sgml. - Get the DocBook - stylesheets and install in - /usr/[local/]lib/sgml/stylesheets + Get the DocBook + stylesheets and install in + /usr/[local/]lib/sgml/stylesheets (thereby creating a subdirectory docbook). For indexing, - copy or link collateindex.pl from the - DocBook stylesheets archive in bin into - a directory on your PATH. - - Download the ISO - entities into - /usr/[local/]lib/sgml. + copy or link collateindex.pl from the + DocBook stylesheets archive in bin into + a directory on your PATH. + + Download the ISO + entities into + /usr/[local/]lib/sgml. @@ -3474,7 +3605,7 @@ $ make way=p Configuring the DocBook tools - Once the DocBook tools are installed, the configure script + Once the DocBook tools are installed, the configure script will detect them and set up the build system accordingly. If you have a system that isn't supported, let us know, and we'll try to help. @@ -3486,12 +3617,12 @@ $ make way=p If you install from source, you'll get a pile of warnings of the form -DTDDECL catalog entries are not supported +DTDDECL catalog entries are not supported every time you build anything. These can safely be ignored, but if you find them tedious you can get rid of them by removing all - the DTDDECL entries from - docbook.cat. + the DTDDECL entries from + docbook.cat. @@ -3569,14 +3700,14 @@ $ make install-docs 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 - . + . 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 . + linkend="unregisterised-porting"/>. @@ -3593,17 +3724,16 @@ $ make install-docs target machine, and compiling them using gcc to get a working GHC. - 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. + NOTE: GHC versions 5.xx were hard to bootstrap + from C. We recommend using GHC 6.0.1 or + later. - HC files are architecture-dependent (but not - OS-dependent), so you have to get a set that were generated on - similar hardware. There may be some supplied on the GHC - download page, otherwise you'll have to compile some up - yourself, or start from unregisterised HC - files - see . + HC files are platform-dependent, so you have to get a set + that were generated on similar hardware. There may be some + supplied on the GHC download page, otherwise you'll have to + compile some up yourself, or start from + unregisterised HC files - see . The following steps should result in a working GHC build with full libraries: @@ -3630,9 +3760,9 @@ $ make install-docs command will execute the whole build process (it won't install yet): - + foo% distrib/hc-build --prefix=dir - + --hc-build By default, the installation directory is @@ -3645,9 +3775,9 @@ foo% distrib/hc-build --prefix=dir build process, you can install the resulting system, as normal, with - + foo% make install - + @@ -3687,65 +3817,239 @@ foo% make install since unregisterised compilation is usually just a step on the way to a full registerised port, we don't mind too much. - - Building an unregisterised port + 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 + experience most systems differ from the standards in one way or + another. Deal with any problems as they arise - if you get + stuck, ask the experts on + glasgow-haskell-users@haskell.org. - The first step is to get some unregisterised HC files. - Either (a) download them from the GHC site (if there are - some available for the right version of GHC), or - (b) build them yourself on any machine with a working - GHC. If at all possible this should be a machine with the - same word size as the target. - - There is a script available which should automate the - process of doing the 2-stage bootstrap necessary to get the - unregisterised HC files - it's available in fptools/distrib/cross-port - in CVS. - - Now take these unregisterised HC files to the target - platform and bootstrap a compiler from them as per the - instructions in . In - build.mk, you need to tell the build - system that the compiler you're building is - (a) unregisterised itself, and (b) builds - unregisterised binaries. This varies depending on the GHC - version you're bootstraping: + Lots of useful information about the innards of GHC is + available in the GHC + Commentary, which might be helpful if you run into some + code which needs tweaking for your system. - -# build.mk for GHC 4.08.x -GhcWithRegisterised=NO - + + Cross-compiling to produce an unregisterised GHC + + In this section, we explain how to bootstrap GHC on a + new platform, using unregisterised intermediate C files. We + haven't put a great deal of effort into automating this + process, for two reasons: it is done very rarely, and the + process usually requires human intervention to cope with minor + porting issues anyway. + + The following step-by-step instructions should result in + a fully working, albeit unregisterised, GHC. Firstly, you + need a machine that already has a working GHC (we'll call this + the host machine), in order to + cross-compile the intermediate C files that we will use to + bootstrap the compiler on the target + machine. + + + + On the target machine: + + + + Unpack a source tree (preferably a released + version). We will call the path to the root of this + tree T. + + + + +$ cd T +$ ./configure --enable-hc-boot --enable-hc-boot-unregisterised + + + You might need to update + configure.in to recognise the new + architecture, and re-generate + configure with + autoreconf. + + + + +$ cd T/ghc/includes +$ make config.h + + + + + + + On the host machine: + + + + Unpack a source tree (same released version). Call + this directory H. + + + + +$ cd H +$ ./configure + + + + + Create + H/mk/build.mk, + with the following contents: -# build.mk for GHC 5.xx -GhcUnregisterised=YES +GhcUnregisterised = YES +GhcLibHcOpts = -O -H32m -keep-hc-files +GhcLibWays = +SplitObjs = NO +GhcWithNativeCodeGen = NO +GhcWithInterpreter = NO +GhcStage1HcOpts = -O -H32m -fasm +GhcStage2HcOpts = -O -fvia-C -keep-hc-files + - Version 5.xx only: use the option - instead of - when running - ./configure. - - The build may not go through cleanly. We've tried to - stick to writing portable code in most parts of the compiler, - so it should compile on any POSIXish system with gcc, but in - our experience most systems differ from the standards in one - way or another. Deal with any problems as they arise - if you - get stuck, ask the experts on - glasgow-haskell-users@haskell.org. - - Once you have the unregisterised compiler up and - running, you can use it to start a registerised port. The - following sections describe the various parts of the system - that will need architecture-specific tweaks in order to get a - registerised build going. - - Lots of useful information about the innards of GHC is - available in the GHC - Commentary, which might be helpful if you run into - some code which needs tweaking for your system. + + Edit + H/mk/config.mk: + + + change TARGETPLATFORM + appropriately, and set the variables involving + TARGET to the correct values for + the target platform. This step is necessary because + currently configure doesn't cope + with specifying different values for the + --host and + --target flags. + + + copy LeadingUnderscore + setting from target. + + + + + + Copy + T/ghc/includes/config.h + to + H/ghc/includes. + Note that we are building on the host machine, using the + target machine's config.h file. This + is so that the intermediate C files generated here will + be suitable for compiling on the target system. + + + + + Touch config.h, just to make + sure it doesn't get replaced during the build: + +$ touch H/ghc/includes/config.h + + + + Now build the compiler: + +$ cd H/glafp-utils && make boot && make +$ cd H/ghc && make boot && make + + Don't worry if the build falls over in the RTS, we + don't need the RTS yet. + + + + +$ cd H/libraries +$ make boot && make + + + + + +$ cd H/ghc +$ make boot stage=2 && make stage=2 + + + + + +$ cd H/ghc/utils +$ make clean +$ make -k HC=H/ghc/compiler/stage1/ghc-inplace \ + EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' + + + + + +$ cd H +$ make hc-file-bundle Project=Ghc + + + + + copy + H/*-hc.tar.gz + to T/... + + + + + + On the target machine: + + At this stage we simply need to bootstrap a compiler + from the intermediate C files we generated above. The + process of bootstrapping from C files is automated by the + script in distrib/hc-build, and is + described in . + + +$ ./distrib/hc-build --enable-hc-boot-unregisterised + + + However, since this is a bootstrap on a new machine, + the automated process might not run to completion the + first time. For that reason, you might want to treat the + hc-build script as a list of + instructions to follow, rather than as a fully automated + script. This way you'll be able to restart the process + part-way through if you need to fix anything on the + way. + + Don't bother with running + make install in the newly + bootstrapped tree; just use the compiler in that tree to + build a fresh compiler from scratch, this time without + booting from C files. Before doing this, you might want + to check that the bootstrapped compiler is generating + working binaries: + + +$ cat >hello.hs +main = putStrLn "Hello World!\n" +^D +$ T/ghc/compiler/ghc-inplace hello.hs -o hello +$ ./hello +Hello World! + + + Once you have the unregisterised compiler up and + running, you can use it to start a registerised port. The + following sections describe the various parts of the + system that will need architecture-specific tweaks in + order to get a registerised build going. + + + @@ -3756,9 +4060,9 @@ GhcUnregisterised=YES - ghc/includes/MachRegs.h - MachRegs.h - + ghc/includes/MachRegs.h + MachRegs.h + Defines the STG-register to machine-register mapping. You need to know your platform's C calling @@ -3768,19 +4072,19 @@ GhcUnregisterised=YES - ghc/includes/TailCalls.h - TailCalls.h - + ghc/includes/TailCalls.h + TailCalls.h + Macros that cooperate with the mangler (see ) to make proper tail-calls + linkend="sec-mangler"/>) to make proper tail-calls work. - ghc/rts/Adjustor.c - Adjustor.c - + ghc/rts/Adjustor.c + Adjustor.c + Support for foreign import "wrapper" @@ -3791,9 +4095,9 @@ GhcUnregisterised=YES - ghc/rts/StgCRun.c - StgCRun.c - + ghc/rts/StgCRun.c + StgCRun.c + The little assembly layer between the C world and the Haskell world. See the comments and code for the @@ -3801,12 +4105,12 @@ GhcUnregisterised=YES - ghc/rts/MBlock.h - ghc/rts/MBlock.c - MBlock.h - - MBlock.c - + ghc/rts/MBlock.h + MBlock.h + + ghc/rts/MBlock.c + MBlock.c + These files are really OS-specific rather than architecture-specific. In MBlock.h @@ -3872,10 +4176,13 @@ GhcUnregisterised=YES To support GHCi, you need to port the dynamic linker (fptools/ghc/rts/Linker.c). The linker currently supports the ELF and PEi386 object file formats - if - your platform uses one of these then you probably don't have - to do anything except fiddle with the - #ifdefs at the top of - Linker.c to tell it about your OS. + 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. If your system uses a different object file format, then you have to write a linker — good luck! @@ -3897,7 +4204,7 @@ WARNINGS about pitfalls and known “problems”: - + @@ -3913,9 +4220,9 @@ of choice). The best way around it is to say - + export TMPDIR=<dir> - + in your build.mk file. Then GHC and the other fptools programs will use the appropriate directory @@ -3947,11 +4254,11 @@ incompatible pointer type” out of GCC. Harmless. Similarly, archiving warning messages like the following are not a problem: - + ar: filename GlaIOMonad__1_2s.o truncated to GlaIOMonad_ ar: filename GlaIOMonad__2_2s.o truncated to GlaIOMonad_ ... - + @@ -3991,15 +4298,15 @@ above. -and try again: gmake. (see for information about +and try again: gmake. (see for information about <module>_HC_OPTS.) Alternatively, just cut to the chase: - + % cd ghc/compiler % make EXTRA_HC_OPTS=-optCrts-M128M - + @@ -4023,13 +4330,13 @@ this bug also suggests that you have an old GCC. You may need to re-ranlibranlib your libraries (on Sun4s). - + % cd $(libdir)/ghc-x.xx/sparc-sun-sunos4 % foreach i ( `find . -name '*.a' -print` ) # or other-shell equiv... ? ranlib $i ? # or, on some machines: ar s $i ? end - + We'd be interested to know if this is still necessary. @@ -4045,18 +4352,18 @@ a bit from one Unix to another. One particular gotcha is macro calls like this: - + SLIT("Hello, world") - + Some cpps treat the comma inside the string as separating two macro arguments, so you get - + :731: macro `SLIT' used with too many (2) args - + Alas, cpp doesn't tell you the offending file! @@ -4065,31 +4372,26 @@ Workaround: don't put weird things in string args to cpp macr - + -Notes for building under Windows - +Platforms, scripts, and file names -This section summarises how to get the utilities you need on your -Win95/98/NT/2000 machine to use CVS and build GHC. Similar notes for -installing and running GHC may be found in the user guide. In general, -Win95/Win98 behave the same, and WinNT/Win2k behave the same. -You should read the GHC installation guide sections on Windows (in the user -guide) before continuing to read these notes. +GHC is designed both to be built, and to run, on both Unix and Windows. This flexibility +gives rise to a good deal of brain-bending detail, which we have tried to collect in this chapter. +Windows platforms: Cygwin, MSYS, and MinGW -Cygwin and MinGW - - The Windows situation for building GHC is rather confusing. This section + The build system is built around Unix-y makefiles. Because it's not native, +the Windows situation for building GHC is particularly confusing. This section tries to clarify, and to establish terminology. -GHC-mingw +MinGW MinGW (Minimalist GNU for Windows) is a collection of header @@ -4099,47 +4401,125 @@ current set of tools include GNU Compiler Collection (gcc), G Utilities (Binutils), GNU debugger (Gdb), GNU make, and a assorted other utilities. -The GHC that we distribute includes, inside the distribution itself, the MinGW gcc, -as, ld, and a bunch of input/output libraries. -GHC compiles Haskell to C (or to -assembly code), and then invokes these MinGW tools to generate an executable binary. -The resulting binaries can run on any Win32 system. + + The down-side of MinGW is that the MinGW libraries do not support anything like the full +Posix interface. - We will call a GHC that targets MinGW in this way GHC-mingw. + + +Cygwin and MSYS + +You can't use the MinGW to build GHC, because MinGW doesn't have a shell, +or the standard Unix commands such as mv, rm, +ls, nor build-system stuff such as make and cvs. +For that, there are two choices: Cygwin +and MSYS: + + + +Cygwin comes with compilation tools (gcc, ld and so on), which +compile code that has access to all of Posix. The price is that the executables must be +dynamically linked with the Cygwin DLL, so that you cannot run a Cywin-compiled program on a machine +that doesn't have Cygwin. Worse, Cygwin is a moving target. The name of the main DLL, cygwin1.dll +does not change, but the implementation certainly does. Even the interfaces to functions +it exports seem to change occasionally. + + + +MSYS is a fork of the Cygwin tree, so they +are fundamentally similar. However, MSYS is by design much smaller and simpler. Access to the file system goes +through fewer layers, so MSYS is quite a bit faster too. + + +Furthermore, MSYS provides no compilation tools; it relies instead on the MinGW tools. These +compile binaries that run with no DLL support, on any Win32 system. +However, MSYS does come with all the make-system tools, such as make, autoconf, +cvs, ssh etc. To get these, you have to download the +MsysDTK (Developer Tool Kit) package, as well as the base MSYS package. + +MSYS does have a DLL, but it's only used by MSYS commands (sh, rm, +ssh and so on), +not by programs compiled under MSYS. + - The down-side of GHC-mingw is that the MinGW libraries do not support anything like the full -Posix interface. So programs compiled with GHC-mingw cannot import the (Haskell) Posix + + + + + +Targeting MinGW + +We want GHC to compile programs that work on any Win32 system. Hence: + + +GHC does invoke a C compiler, assembler, linker and so on, but we ensure that it only +invokes the MinGW tools, not the Cygwin ones. That means that the programs GHC compiles +will work on any system, but it also means that the programs GHC compiles do not have access +to all of Posix. In particular, they cannot import the (Haskell) Posix library; they have to do -their input output using standard Haskell I/O libraries, or native Win32 bindings. +their input output using standard Haskell I/O libraries, or native Win32 bindings. + We will call a GHC that targets MinGW in this way GHC-mingw. + + + +To make the GHC distribution self-contained, the GHC distribution includes the MinGW gcc, +as, ld, and a bunch of input/output libraries. + + +So GHC targets MinGW, not Cygwin. +It is in principle possible to build a version of GHC, GHC-cygwin, +that targets Cygwin instead. The up-side of GHC-cygwin is +that Haskell programs compiled by GHC-cygwin can import the (Haskell) Posix library. +We do not support GHC-cygwin, however; it is beyond our resources. + + +While GHC targets MinGW, that says nothing about +how GHC is built. We use both MSYS and Cygwin as build environments for +GHC; both work fine, though MSYS is rather lighter weight. + +In your build tree, you build a compiler called ghc-inplace. It +uses the gcc that you specify using the + flag when you run +configure (see below). +The makefiles are careful to use ghc-inplace (not gcc) +to compile any C files, so that it will in turn invoke the correct gcc rather that +whatever one happens to be in your path. However, the makefiles do use whatever ld +and ar happen to be in your path. This is a bit naughty, but (a) they are only +used to glom together .o files into a bigger .o file, or a .a file, +so they don't ever get libraries (which would be bogus; they might be the wrong libraries), and (b) +Cygwin and MinGW use the same .o file format. So its ok. -GHC-cygwin + File names -There is a way to get the full Posix interface, which is to use Cygwin. -Cygwin is a complete Unix simulation that runs on Win32. -Cygwin comes with a shell, and all the usual Unix commands: mv, rm, -ls, plus of course gcc, ld and so on. -A C program compiled with the Cygwin gcc certainly can use all of Posix. +Cygwin, MSYS, and the underlying Windows file system all understand file paths of form c:/tmp/foo. +However: + + +MSYS programs understand /bin, /usr/bin, and map Windows's lettered drives as +/c/tmp/foo etc. The exact mount table is given in the doc subdirectory of the MSYS distribution. -So why doesn't GHC use the Cygwin gcc and libraries? Because -Cygwin comes with a DLL that must be linked with every runnable Cygwin-compiled program. -A program compiled by the Cygwin tools cannot run at all unless Cygwin is installed. -If GHC targeted Cygwin, users would have to install Cygwin just to run the Haskell programs -that GHC compiled; and the Cygwin DLL would have to be in the DLL load path. -Worse, Cygwin is a moving target. The name of the main DLL, cygwin1.dll -does not change, but the implementation certainly does. Even the interfaces to functions -it exports seem to change occasionally. So programs compiled by GHC might only run with -particular versions of Cygwin. All of this seems very undesirable. + When it invokes a command, the MSYS shell sees whether the invoked binary lives in the MSYS /bin +directory. If so, it just invokes it. If not, it assumes the program is no an MSYS program, and walks over the command-line +arguments changing MSYS paths into native-compatible paths. It does this inside sub-arguments and inside quotes. For example, +if you invoke + + foogle -B/c/tmp/baz + +the MSYS shell will actually call foogle with argument -Bc:/tmp/baz. + + + +Cygwin programs have a more complicated mount table, and map the lettered drives as /cygdrive/c/tmp/foo. - -Nevertheless, it is certainly possible to build a version of GHC that targets Cygwin; -we will call that GHC-cygwin. The up-side of GHC-cygwin is -that Haskell programs compiled by GHC-cygwin can import the (Haskell) Posix library. +The Cygwin shell does no argument processing when invoking non-Cygwin programs. + + -HOST_OS vs TARGET_OS +Host System vs Target System In the source code you'll find various ifdefs looking like: @@ -4157,64 +4537,173 @@ and These macros are set by the configure script (via the file config.h). Which is which? The criterion is this. In the ifdefs in GHC's source code: + + The "host" system is the one on which GHC itself will be run. + + + The "target" system is the one for which the program compiled by GHC will be run. + + +For a stage-2 compiler, in which GHCi is available, the "host" and "target" systems must be the same. +So then it doesn't really matter whether you use the HOST_OS or TARGET_OS cpp macros. + + + + + + +Wrapper scripts + + +Many programs, including GHC itself and hsc2hs, need to find associated binaries and libraries. +For installed programs, the strategy depends on the platform. We'll use +GHC itself as an example: + - The "host" system is the one on which GHC itself will be run. + On Unix, the command ghc is a shell script, generated by adding installation + paths to the front of the source file ghc.sh, + that invokes the real binary, passing "-Bpath" as an argument to tell ghc + where to find its supporting files. + - The "target" system is the one for which the program compiled by GHC will be run. + On vanilla Windows, it turns out to be much harder to make reliable script to be run by the + native Windows shell cmd (e.g. limits on the length + of the command line). So instead we invoke the GHC binary directly, with no -B flag. + GHC uses the Windows getExecDir function to find where the executable is, + and from that figures out where the supporting files are. -For a stage-2 compiler, in which GHCi is available, the "host" and "target" systems must be the same. -So then it doesn't really matter whether you use the HOST_OS or TARGET_OS cpp macros. +(You can find the layout of GHC's supporting files in the + section "Layout of installed files" of Section 2 of the GHC user guide.) + + +Things work differently for in-place execution, where you want to +execute a program that has just been built in a build tree. The difference is that the +layout of the supporting files is different. +In this case, whether on Windows or Unix, we always use a shell script. This works OK +on Windows because the script is executed by MSYS or Cygwin, which don't have the +shortcomings of the native Windows cmd shell. + + + + + +Instructions for building under Windows + + +This section gives detailed instructions for how to build +GHC from source on your Windows machine. Similar instructions for +installing and running GHC may be found in the user guide. In general, +Win95/Win98 behave the same, and WinNT/Win2k behave the same. - + +Make sure you read the preceding section on platforms () +before reading section. +You don't need Cygwin or MSYS to use GHC, +but you do need one or the other to build GHC. -Summary -Notice that "GHC-mingw" means "GHC that targets MinGW". It says nothing about -how that GHC was built. It is entirely possible to have a GHC-mingw that was built -by compiling GHC's Haskell sources with a GHC-cygwin, or vice versa. +Installing and configuring MSYS -We distribute only a GHC-mingw built by a GHC-mingw; supporting -GHC-cygwin too is beyond our resources. The GHC we distribute -therefore does not require Cygwin to run, nor do the programs it -compiles require Cygwin. + +MSYS is a lightweight alternative to Cygwin. +You don't need MSYS to use GHC, +but you do need it or Cygwin to build GHC. +Here's how to install MSYS. + + +Go to http://www.mingw.org/download.shtml and +download the following (of course, the version numbers will differ): + + The main MSYS package (binary is sufficient): MSYS-1.0.9.exe + + The MSYS developer's toolkit (binary is sufficient): msysDTK-1.0.1.exe. + This provides make, autoconf, + ssh, cvs and probably more besides. + + +Run both executables (in the order given above) to install them. I put them in c:/msys + -The instructions that follow describe how to build GHC-mingw. It is -possible to build GHC-cygwin, but it's not a supported route, and the build system might -be flaky. + +Set the following environment variables + + PATH: add c:/msys/1.0/bin to your path. (Of course, the version number may differ.) + -In your build tree, you build a compiler called ghc-inplace. It -uses the gcc that you specify using the - flag when you run -configure (see below). -The makefiles are careful to use ghc-inplace (not gcc) -to compile any C files, so that it will in turn invoke the right gcc rather that -whatever one happens to be in your path. However, the makefiles do use whatever ld -and ar happen to be in your path. This is a bit naughty, but (a) they are only -used to glom together .o files into a bigger .o file, or a .a file, -so they don't ever get libraries (which would be bogus; they might be the wrong libraries), and (b) -Cygwin and Mingw use the same .o file format. So its ok. + HOME: set to your home directory (e.g. c:/userid). + This is where, among other things, ssh will look for your .ssh directory. + + + SHELL: set to c:/msys/1.0/bin/sh.exe + + + CVS_RSH: set to c:/msys/1.0/bin/ssh.exe. Only necessary if + you are using CVS. + + + MAKE_MODE: set to UNIX. (I'm not certain this is necessary for MSYS.) + + + + + + +Check that the CYGWIN environment variable is not set. It's a bad bug +that MSYS is affected by this, but if you have CYGWIN set to "ntsec ntea", which is right for Cygwin, it +causes the MSYS ssh to bogusly fail complaining that your .ssh/identity +file has too-liberal permissinos. + + + - - +Here are some points to bear in mind when using MSYS: + + MSYS does some kind of special magic to binaries stored in +/bin and /usr/bin, which are by default both mapped +to c:/msys/1.0/bin (assuming you installed MSYS in c:/msys). +Do not put any other binaries (such as GHC or Alex) in this directory or its sub-directories: +they fail in mysterious ways. However, it's fine to put other binaries in /usr/local/bin, +which maps to c:/msys/1.0/local/bin. + + MSYS seems to implement symbolic links by copying, so sharing is lost. + -Installing and configuring Cygwin + +Win32 has a find command which is not the same as MSYS's find. +You will probably discover that the Win32 find appears in your PATH +before the MSYS one, because it's in the system PATH +environment variable, whereas you have probably modified the user PATH +variable. You can always invoke find with an absolute path, or rename it. + -You don't need Cygwin to use GHC, -but you do need it to build GHC. + +MSYS comes with bzip, and MSYS's tar's -j +will bunzip an archive (e.g. tar xvjf foo.tar.bz2). Useful when you get a +bzip'd dump. - Install Cygwin from http://www.cygwin.com/. -The installation process is straightforward; we install it in c:/cygwin. -During the installation dialogue, make sure that you select: -cvs, openssh, -autoconf, -binutils (includes ld and (I think) ar), -gcc, -flex, -make. + + + +Installing and configuring Cygwin + + Install Cygwin from http://www.cygwin.com/. +The installation process is straightforward; we install it in c:/cygwin. +During the installation dialogue, make sure that you select all of the following: + cvs, + openssh, + autoconf, + binutils (includes ld and (I think) ar), + gcc, + flex, + make. +If you miss out any of these, strange things will happen to you. To see thse packages, +click on the "View" button in the "Select Packages" +stage of Cygwin's installation dialogue, until the view says "Full". The default view, which is +"Category" isn't very helpful, and the "View" button is rather unobtrousive. Now set the following user environment variables: @@ -4224,17 +4713,17 @@ During the installation dialogue, make sure that you select: -Set MAKE_MODE to UNIX. If you +Set MAKE_MODE to UNIX. If you don't do this you get very weird messages when you type -make, such as: - +make, such as: + /c: /c: No such file or directory - + Set SHELL to -c:/cygwin/bin/sh. When you invoke a shell in Emacs, this +c:/cygwin/bin/bash. When you invoke a shell in Emacs, this SHELL is what you get. @@ -4267,21 +4756,21 @@ you can't rename a running program! -Some script files used in the make system start with "#!/bin/perl", -(and similarly for sh). Notice the hardwired path! -So you need to ensure that your /bin directory has the following +Some script files used in the make system start with "#!/bin/perl", +(and similarly for sh). Notice the hardwired path! +So you need to ensure that your /bin directory has the following binaries in it: - sh - perl - cat + sh + perl + cat -All these come in Cygwin's bin directory, which you probably have -installed as c:/cygwin/bin. By default Cygwin mounts "/" as -c:/cygwin, so if you just take the defaults it'll all work ok. +All these come in Cygwin's bin directory, which you probably have +installed as c:/cygwin/bin. By default Cygwin mounts "/" as +c:/cygwin, so if you just take the defaults it'll all work ok. (You can discover where your Cygwin -root directory / is by typing mount.) -Provided /bin points to the Cygwin bin +root directory / is by typing mount.) +Provided /bin points to the Cygwin bin directory, there's no need to copy anything. If not, copy these binaries from the cygwin/bin directory (after fixing the sh.exe stuff mentioned in the previous bullet). @@ -4305,20 +4794,93 @@ they don't recognise symlinks. -Win32 has a find command which is not the same as Cygwin's find. -You will probably discover that the Win32 find appears in your PATH -before the Cygwin one, because it's in the system PATH -environment variable, whereas you have probably modified the user PATH -variable. You can always invoke find with an absolute path, or rename it. +See the notes in about find and bzip, +which apply to Cygwin too. - + + -Other things you need to install +Configuring SSH -You have to install the following other things to build GHC: +ssh comes with Cygwin, provided you remember to ask for it when +you install Cygwin. (If not, the installer lets you update easily.) Look for openssh +(not ssh) in the Cygwin list of applications! + +There are several strange things about ssh on Windows that you need to know. + + + + The programs ssh-keygen1, ssh1, and cvs, + seem to lock up bash entirely if they try to get user input (e.g. if + they ask for a password). To solve this, start up cmd.exe + and run it as follows: + + c:\tmp> set CYGWIN32=tty + c:\tmp> c:/user/local/bin/ssh-keygen1 + + + + (Cygwin-only problem, I think.) +ssh needs to access your directory .ssh, in your home directory. +To determine your home directory ssh first looks in +c:/cygwin/etc/passwd (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, ignoring +the setting of the environment variable $HOME. If the home directory is +bogus, ssh fails horribly. The best way to see what is going on is to say + + ssh -v cvs.haskell.org + +which makes ssh print out information about its activity. + + You can fix this problem, either by correcting the home-directory field in +c:/cygwin/etc/passwd, or by simply deleting the entire entry for your userid. If +you do that, ssh uses the $HOME environment variable instead. + + + + + + To protect your + .ssh from access by anyone else, + right-click your .ssh directory, and + select Properties. 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! + + + + In fact ssh 3.6.1 now seems to require + you to have Unix permissions 600 (read/write for owner only) + on the .ssh/identity file, else it + bombs out. For your local C drive, it seems that chmod 600 identity 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 "ntsec neta". The $CYGWIN environment variable is discussed + in the Cygwin User's Guide, + and there are more details in the Cygwin FAQ. + + + + + + +Other things you need to install + +You have to install the following other things to build GHC, listed below. + +On Windows you often install executables in directories with spaces, such as +"Program Files". However, the make system for fptools 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, +/usr/local/bin and /usr/local/lib. But it doesn't matter, +provided they are in your path. @@ -4332,22 +4894,37 @@ you need to add upon completion. Install an executable Happy, from http://www.haskell.org/happy. -Happy is a parser generator used to compile the Haskell grammar. Add it in your +Happy is a parser generator used to compile the Haskell grammar. Under MSYS or Cygwin you can easily +build it from the source distribution using + + ./configure + make + make install + +This should install it in /usr/local/bin (which maps to c:/msys/1.0/local/bin +on MSYS). +Make sure the installation directory is in your PATH. + + Install Alex. This can be done by building from the + source distribution in the same way as Happy. Sources are + available from http://www.haskell.org/alex. + GHC uses the mingw C compiler to -generate code, so you have to install that (see ). +generate code, so you have to install that (see ). Just pick up a mingw bundle at http://www.mingw.org/. We install it in c:/mingw. Do not add any of the mingw binaries to your path. They are only going to get used by explicit access (via the --with-gcc flag you -give to configure later). If you do add them to your path +give to configure later). If you do add them to your path you are likely to get into a mess because their names overlap with Cygwin binaries. @@ -4367,26 +4944,25 @@ so you will need to add emacs/bin to your PATH Finally, check out a copy of GHC sources from -the CVS repository, following the instructions above (). +the CVS repository, following the instructions above (). -Building GHC +Building GHC OK! -Now go read the documentation above on building from source (); +Now go read the documentation above on building from source (); the bullets below only tell you about Windows-specific wrinkles. - + -Run autoconf both in fptools -and in fptools/ghc. If you omit the latter step you'll -get an error when you run ./configure: - +If you used autoconf instead of autoreconf, +you'll get an error when you run ./configure: + ...lots of stuff... creating mk/config.h mk/config.h is unchanged @@ -4394,12 +4970,12 @@ configuring in ghc running /bin/sh ./configure --cache-file=.././config.cache --srcdir=. ./configure: ./configure: No such file or directory configure: error: ./configure failed for ghc - + - autoconf seems to create the file configure -read-only. So if you need to run autoconf again (which I sometimes do for safety's sake), + autoreconf seems to create the file configure +read-only. So if you need to run autoreconf again (which I sometimes do for safety's sake), you get /usr/bin/autoconf: cannot create configure: permission denied @@ -4408,60 +4984,79 @@ Solution: delete configure first. - -You either need to add ghc to your -PATH before you invoke -configure, or use the configure -option . - - - - -If you are paranoid, delete config.cache if it exists. -This file occasionally remembers out-of-date configuration information, which -can be really confusing. - - - - - After autoconf run ./configure in + After autoreconf run ./configure in fptools/ thus: - + ./configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc - + This is the point at which you specify that you are building GHC-mingw -(see ). +(see ). 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 gcc, not a cygwin path, because GHC (which -uses this path to invoke gcc) is a Mingw program and won't -understand a cygwin path.. For example, if you +trouble using the wrong C compiler! + +Furthermore, it's very important that you specify a +full MinGW path for gcc, not a Cygwin path, because GHC (which +uses this path to invoke gcc) is a MinGW program and won't +understand a Cygwin path. For example, if you say --with-gcc=/mingw/bin/gcc, it'll be interpreted as /cygdrive/c/mingw/bin/gcc, 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: + +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 + +Be warned! -If you want to build GHC-cygwin () +If you want to build GHC-cygwin () you'll have to do something more like: - + ./configure --with-gcc=...the Cygwin gcc... - + + + + + +If you are paranoid, delete config.cache if it exists. +This file occasionally remembers out-of-date configuration information, which +can be really confusing. + + + + You almost certainly want to set + + SplitObjs = NO + +in your build.mk configuration file (see ). +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. Do not attempt to build the documentation. It needs all kinds of wierd Jade stuff that we haven't worked out for Win32. - - + + -
+