Troubleshooting the GHC build

Here we keep track of failures that can occur when building GHC, with solutions.

We don't expect anyone to read this page from beginning to end. The only way you get here is by searching, so remember when adding a new entry the most important thing to do is to include the error message verbatim, so searches will find it. If a build failure is caused by a bug in GHC or the build system, please link to the ticket number so we can tell when it's safe to remove the entry and keep this page from getting too crufty.

Permission denied errors on Windows that go away when the build is restarted

A common cause of "permission denied" or "Access denied" errors during a build on Windows is having a realtime virus scanner. If you have a virus scanner turned on, try excluding the GHC build directory from realtime scanning if your virus scanner supports it, or otherwise disable the scanner while building GHC. See Building/Preparation/Windows.

Make has restarted itself 3 times; is there a makefile bug?

If you see this when building:

ghc.mk:96: *** Make has restarted itself 3 times; is there a makefile bug?. Stop.

Simon M says: this can happen if you modify something while the build is in progress - I
see this quite often. In this case the error is just overly conservative, and restarting is the right workaround.

If you encounter this without touching any files after typing 'make',
then it's probably a bug in the build system. Though unfortunately it's
going to be almost impossible to track down unless we can find a way to
reproduce it.

libraries/ghc-prim/GHC/PrimopWrappers.hs:48:18: Not in scope: `GHC.Prim.gcdInt#'

If you get this message when the build system runs Haddock

libraries/ghc-prim/GHC/PrimopWrappers.hs:48:18:
Not in scope: `GHC.Prim.gcdInt#'

it's probably because you have a file PrimopWrappers.hs in the source-code directory libraries/ghc-prim/GHC/. It's a derived file, and is now generated into libraries/ghc-prim/dist-install/build/GHC/. Just remove the offending files (probably PrimopWrappers.hs and Prim.hs) from the source directory and try again.

tar: unable to record current working directory: No such file or directory

This happened to me with an old version of the shell (say "sh --version"). I think perhaps the path-mangling is different. With the MSYS recommended here, all is well. The shell there is version 3.1.0(1).

This is almost certainly because you have stale interface files (Foo.hi) lying around, and GHC's binary interface-file format has changed. Try make distclean and rebuild. If you still get it, use find to find *.hi and remove them.

A dialog pops up: “Reflect_hsc_make.exe has stopped working”, with the buttons “Debug” and “Close program”.

This signals an obscure problem whose source is still unknown:
if GHC links in certain Windows libraries, kernel32 and msvcrt, the resulting program crashes.
See ​Sigbjorn's email. We wish we knew why!

We've worked around this in GHC 6.10.4 (and later) so that the problem shouldn't arise if you use that to build GHC with. But if you have an earlier GHC on your machine you can still work around it as follows. These two commands will fix up the base and Win32 packages respectively to remove the offending libraries from extra-libraries and add a suitable extra-ghci-libraries:

Sadly the argument list has a limited length in Windows. This may be fixable
somehow (Windows expertise welcomed here), but what we do is to set

SplitObjs = NO

in build.mk. That stops the splitting-up of object files, and dramatically reduces
the number of object files involved. Link times are also improved. (Binary size increases
though.)

Also, you can arrange for the (huge) list of files to be processed iteratively, rather all at once, and that would probably be a principal solution. xargs feeds the file names to the appropriate command (e.g. ar). In $(GHC_TOP)/mk/target.mk find the place where it is called and add this switch

xargs -n NNN

where NNN is the number of arguments processed at a time. It should be small enough to be less than the limit and large enough for the whole thing not to be too slow.

Note, that it's not good to edit target.mk in general.

Space in TMPDIR

One difficulty that comes up from time to time is running out of space
in TMPDIR. (It is impossible for the configuration stuff to
compensate for the vagaries of different sysadmin approaches to temp
space.)

The quickest way around it is setenv TMPDIR /usr/tmp or
even setenv TMPDIR . (or the equivalent incantation with your shell
of choice).

The best way around it is to say

export TMPDIR=<dir>

in your build.mk file. Then GHC and the other
tools will use the appropriate directory in all cases.

Warning "warning: assignment from incompatible pointer type"

You may occasionally see a warning from the C compiler when compiling some
Haskell code, eg. "warning: assignment from
incompatible pointer type". These are usually harmless, but it's a good idea to
report it on the mailing list so that we can fix it.

Warning "ar: filename GlaIOMonad__1_2s.o truncated to GlaIOMonad_"

Similarly, archiving warning messages like the following are not a problem:

What is happening is that the ghc build system is linking thousands and
thousands of tiny .o files into libHSbase.a. GNU ar isn't optimised for
this use-case and it takes far more memory than it really needs to. So
what happens is that ar takes >500Mb of memory and your virtual
machine / virtual server probably isn't configured with that much memory
and so the linux kernel OOM killer terminates the ar process.

To make this worse, since there are so many .o files, it takes several
invocations of ar to link them all. On each invocation ar is building
the symbol index (-q is ignored) and this is what takes the most time
and memory. It's a good deal quicker to use a custom program (100 lines
of Haskell) to build libHSbase.a and then use ranlib just once to build
the symbol index.

[Duncan Coutts] I submitted a patch to gnu binutils to make ar take less memory when
linking 1000's of files so it now only takes around 100Mb rather than
500Mb when linking libHSbase.a. That patch is included in version 2.17 I
think (in other words most systems don't have it yet).

What you can do in the mean time is either configure your virtual
machine with more memory or turn off the split-objs feature when you
configure ghc. Just add SplitObjs=NO to your mk/build.mk file (which
may not exist to start with). (The Gentoo ebuild does this
automatically)

Crippled ld

It turns out that on both Cygwin and MSYS, the ld has a
limit of 32kbytes on its command line. Especially when using split object
files, the make system can emit calls to ld with thousands
of files on it. Then you may see something like this:

The solution is either to switch off object file splitting (set
SplitObjs to NO in your
build.mk),
or to make the module smaller.

CYGWIN environment variable in MSYS

When using 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.

then you have probably not got automake installed (or at least findable).

Vista installer detection

Vista has a "feature" called "installer detection" which tries to elevate permissinos for executables named things like Setup and Install. There are lots of programs called Setup in a GHC build, and if you see permission-denied errors relating to programs called Setup you may need to disable installer detection. Go to Start -> All Programs -> Accessories > Run and enter secpol.msc. Then under Security Settings -> Local Policies -> Security Options, disable UAC: Detect application installations and prompt for elevation. Then reboot.

We added a workaround for install-detection in GHC 6.8.1 (see #1271), so if you're using that version or later you shouldn't encounter this issue.

Cygwin: failure to use native path to gcc when configuring

It's very important that you specify a
native Windows path for gcc, not a Cygwin path, because GHC (which
uses this path to invoke gcc) is a Windows program and won't
understand a Cygwin path. For example, you want to say something like --with-gcc=c:/mingw/bin/gcc.exe and not--with-gcc=/cygdrive/c/mingw/bin/gcc.exe or --with-gcc=/mingw/bin/gcc.exe. If you get this wrong, the failure might come with no error message whatsoever. GHC simply fails silently when first invoked,
typically leaving you with this:

Ubuntu: dash vs bash

In Ubuntu 6.10 the default system shell /bin/sh was changed to dash (The Debian Almquist Shell) instead of bash, see ​DashAsBinSh. This has been reported to break the GHC build. Until the GHC scripts are updated, the easiest way to fix this problem is to (as root) change the /bin/sh link back to /bin/bash. There should be minimal effect on the rest of the system, bar a small speed penalty for script heavy processes due to bash slowness.

This error occurs when using the new build system with MSYS on Windows. It is a temporary error; just type make again to continue the build. Hopefully this is a bug in MSYS that will be fixed at some point.

/usr/bin/patch: Permission denied

This happened to me with MSYS on Windows Server 2003. Exact cause unknown, but it seems that Windows Server 2003 was upset by the patch.exe.manifest supplied with MSYS alongside patch.exe to work around the installer-detection nonsense on Vista. Workaround: remove /usr/bin/patch.exe.manifest.

Relocation error when linking the RTS shared library

If you use a system with an older GCC (4.1.2 in my case), you may run into the following error:

The Scientific Linux system I was building on had the following software installed:
kernel 2.6.18-128.1.1.el5
gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
GNU ld version 2.17.50.0.6-9.el5 20061020 (that's the binutils version afaik)
Bootstrapping GHC was version 6.12.1.

As far as I could tell all .dyn_o files had been built to allow relocation, but StgCRun.c contains some inline assembler code that specifically targets the x86 and x86_64. Upon removal and using the generic version (the part that's protected by the #ifdef USE_MINIINTERPRETER), the error shifted to another file, so the problem did not seem to be with that specific symbol that was referenced in RtsStartup.c

There was another GCC on the system however (4.3.3). Using that version did allow GHC to build.