From 4f7abbdceb83d96ac400488a665245a4b67820ba Mon Sep 17 00:00:00 2001 From: Simon Marlow Date: Wed, 10 May 2006 11:52:36 +0000 Subject: [PATCH] some tweaks to the HC bootstrapping instructions --- docs/building/building.xml | 93 +++++++++++++++++++++++++++----------------- 1 file changed, 58 insertions(+), 35 deletions(-) diff --git a/docs/building/building.xml b/docs/building/building.xml index d1b203c..04cf05e 100644 --- a/docs/building/building.xml +++ b/docs/building/building.xml @@ -2351,24 +2351,25 @@ $ make install Porting GHC This section describes how to port GHC to a currenly - unsupported platform. There are two distinct - possibilities: + unsupported platform. To avoid confusion, when we say + “architecture” we are referring to the processor, and + we use the term “platform” to refer to the combination + of architecture and operating system. + + There are two distinct porting scenarios: - The hardware architecture for your system is already - supported by GHC, but you're running an OS that isn't - supported (or perhaps has been supported in the past, but - currently isn't). This is the easiest type of porting job, - but it still requires some careful bootstrapping. Proceed to - . + Your platform is already supported, but you want to + compile up GHC using just a C compiler. This is a + straightforward bootstrap from HC files, and is described in + . - 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 . + Your platform isn't supported by GHC. You will need to + do an unregisterised bootstrap, proceed + to . @@ -2389,25 +2390,40 @@ $ make install later. HC files are platform-dependent, so you have to get a set - that were generated on the same platform. 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 . + that were generated on the same platform. + There may be some supplied on the GHC download page, otherwise + you'll have to compile some up yourself. The following steps should result in a working GHC build with full libraries: - Unpack the HC files on top of a fresh source tree - (make sure the source tree version matches the version of - the HC files exactly!). This will - place matching .hc files next to the - corresponding Haskell source (.hs or - .lhs) in the compiler subdirectory - ghc/compiler and in the libraries - (subdirectories of + Make a set of HC files. On an identical system with + GHC already installed, get a GHC source tree and put the + following in mk/build.mk: + + +SRC_HC_OPTS = -H32m -O -fasm -Rghc-timing -keep-hc-files +GhcLibHcOpts = -O +GhcLibWays = +SplitObjs = NO + + + Build GHC as normal, and then make + hc-file-bundle Project=ghc to creates the tar file + containing the hc files. + + + + On the target system, unpack the HC files on top of a + fresh source tree (make sure the source tree version matches + the version of the HC files exactly!). + This will place matching .hc files next + to the corresponding Haskell source + (.hs or .lhs) in + the compiler subdirectory ghc/compiler + and in the libraries (subdirectories of libraries). @@ -2439,10 +2455,10 @@ $ make install - Porting GHC to a new architecture + Porting GHC to a new platform - The first step in porting to a new architecture is to get - an unregisterised build working. An + The first step in porting to a new platform is to get an + unregisterised build working. An unregisterised build is one that compiles via vanilla C only. By contrast, a registerised build uses the following architecture-specific hacks for speed: @@ -2473,6 +2489,13 @@ $ make install since unregisterised compilation is usually just a step on the way to a full registerised port, we don't mind too much. + You should go through this process even if your + architecture is already has registerised support in GHC, but + your OS currently isn't supported. In this case you probably + won't need to port any of the architecture-specific parts of the + code, and you can proceed straight from the unregisterised build + to build a registerised compiler. + 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 @@ -2529,7 +2552,7 @@ $ ./configure --enable-hc-boot --enable-hc-boot-unregisterised You might need to update configure.in to recognise the new - architecture, and re-generate + platform, and re-generate configure with autoreconf. @@ -2851,15 +2874,15 @@ Hello World! GHCi To support GHCi, you need to port the dynamic linker - ($(GHC_TOP)/rts/Linker.c). The linker - currently supports the ELF and PEi386 object file formats - if - your platform uses one of these then things will be - significantly easier. The majority of Unix platforms use the - ELF format these days. Even so, there are some + ($(GHC_TOP)/rts/Linker.c). The + linker currently supports the ELF and PEi386 object file + formats - if your platform uses one of these then things will + be significantly easier. The majority of Unix platforms use + the ELF format these days. Even so, there are some machine-specific parts of the ELF linker: for example, the code for resolving particular relocation types is machine-specific, so some porting of this code to your - architecture will probaly be necessary. + architecture and/or OS will probaly be necessary. If your system uses a different object file format, then you have to write a linker — good luck! -- 1.7.10.4