wiki:Building/Troubleshooting

Version 1 (modified by simonmar, 6 years ago) (diff)

Moving common build errors into one page

Troubleshooting the GHC build

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

Using autoconf by mistake

If you used autoconf instead of sh boot, you'll get an error when you run ./configure:

...lots of stuff...
creating mk/config.h
mk/config.h is unchanged
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

Cannot create configure

autoreconf (which gets run by sh boot) seems to create the file configure read-only. So if you need to run sh boot again (which I sometimes do for safety's sake), you get

/usr/bin/autoconf: cannot create configure: permission denied

Solution: delete configure first.

Configure can't find darcs version

When you run your configure script, it falls over with

sh-2.04$ ./configure --with-gcc=c:/mingw/bin/gcc --with-ld=c:/mingw/bin/ld.exe --host=i386-unknown-mingw32
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
checking for GHC version date... -nThe system cannot find the file specified.
configure: error: failed to detect version date: check that darcs is in your path

This error is nothing to do with darcs! The darcs-version test in configure uses sort, and it is picking up the Windows sort (in c:\windows\system32) instead of the MSYS or Cygwin sort.

Solution: either hack the configure script by hand, or (better) make sure that MSYS/Cygwin are in your PATH before Windows. Since c:\windows\system32 is, by default, in the System Environment Variable called PATH, and System Variables come first when searching for paths, you'll have to put MSYS/Cygwin bin directory in the System PATH, before c:\windows\system32.

(Incidentally, find is another program that Windows has too, with different functionality to Unix.)

Aregument list too long

You may find this towards the end of compiling the base library:

c:\ghc\ghc-6.6.1\bin\ar.exe: creating libHSbase.a
xargs: c:/ghc/ghc-6.6.1/bin/ar: Argument list too long
make[2]: *** [libHSbase.a] Error 126
make[2]: *** Deleting file `libHSbase.a'
Failed making all in base: 1
make[1]: *** [all] Error 1
make[1]: Leaving directory `/cygdrive/c/GHC6.6.1/ghc-6.6.1/libraries'
make: *** [stage1] Error 2

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.