Compiling GHC from sources
I’ve decided that the best way to learn about the internals of GHC is to actually look at it’s source code in parallel with some experiments. This is the first part of a series of articles related to some GHC experiments, maybe going towards a
ghcd command. But, until then, we have much work to do.
The first step is to have a build which will not affect the existing GHC executable. Thus, I’ve created a Vmware Virtual Machine, installed Ubuntu 10.04 on it and some more packages (
gitk package is not really needed, I used it only to view the git repository status in a somewhat graphical way. However, the
openssh-server and the
mdns-scan were needed so that I could type
ssh haskell.local to create a SSH connection to the virtual machine (named haskell, of course). This way, I won’t be bothered by the switching between the virtual machine interface and the real one.
After this, I did another optional step: I’ve set up my prompt to inform me if I’m working on the machine or on the real system (I prefer to use various prompts across different domains rather that look at the hostname). This was simple, I’ve set up the PS1 shell variable thus:
PS1="[\W] \[33[01;32m\]λ\[33[&zwj00m\] ” in the
.bashrc file. This way, the prompt would be a green lambda and only the basename of the working directory will be shown.
Next, I’ve installed the packages that GHC needed. Although
zlib-dev was not found,
libcurl-dev was replaced by
libcurl4-openssl-dev and another alternative and
docbook-utils it the single
docbook* package that could be found (installed
dblatex as a replacement for the
docbook-utils-pdf package), I could carry on with the source compilation, as you will see in the following steps.
I’ve downloaded the source tree using
darcs and this command:
darcs get --lazy http://darc.haskell.org/ghc
After doing a
cd ghc/ and giving the required rights to the
darcs-all script, I’ve obtained the testing framework:
chmod +x darcs-all
./darcs-all --testsuite get
Then, I started the autoreconf part of the instalation. While running, as instructed from the tutorial,
I’ve thought that I’d like to have a way to see what’s changed in the source tree. Since darcs is not something I’m proficient on, I’ve used git (warning: the git related steps are all optional):
git add .
git commit -m"Initial"
After waiting a little, I’ve started the configuration step. Because I didn’t want to destroy the existing GHC I’ve used a local prefix argument:
git add .
git commit -m"Post conf"
Then, I’ve modified the build configuration. Since the experiment included modifying GHC’s sources, I decided to go for the quickest build possible. After creating a copy of
mk/build.mk, I’ve changed a line in that file, just like this page said (and the tutorial omitted to say). I won’t post the changeset or any other more git commands, since this will take space here and I want to keep this post under 500 actual words.
After this, the last step was to run
make and wait. When it has finished, the build tree contained an
inplace dir which looked exactly like a copy of a GHC install (for example, the
ghc program was in
inplace/bin/ghc-stage2). This is why the above prefix setting was useless.
However, I’ve decided to also run some tests on the code (this is why I downloaded the testsuite in the first place):
After several minutes of spitting things into the terminal, the testing is finished with the following output:
OVERALL SUMMARY for test run started at Sat Oct 16 03:01:30 PDT 2010
2608 total tests, which gave rise to
9749 test cases, of which
0 caused framework failures
7443 were skipped
2220 expected passes
62 expected failures
0 unexpected passes
24 unexpected failures
Not too bad for a start. Now, I only have to make sure that those are the only tests that are failing on my machine when doing the experiments.
That’s all for today. Next post will be about how a simple source file is transformed into the GHC pipeline.