... | ... | @@ -13,7 +13,7 @@ We don't expect anyone to read this page from beginning to end. The only way yo |
|
|
## Segmentation fault and "strange closure type" panics
|
|
|
|
|
|
|
|
|
If the build fails with a `segmentation fault (core dumped)` or a `strange closure type` panic from GHC, but the error goes away or occurs in a different place when you restart the build, then the problem is most likely with your hardware. Please run a [ memtest](http://www.memtest.org/) before going any further.
|
|
|
If the build fails with a `segmentation fault (core dumped)` or a `strange closure type` panic from GHC, but the error goes away or occurs in a different place when you restart the build, then the problem is most likely with your hardware. Please run a [memtest](http://www.memtest.org/) before going any further.
|
|
|
|
|
|
## Permission denied errors on Windows that go away when the build is restarted
|
|
|
|
... | ... | @@ -36,7 +36,7 @@ then it could mean you have introduced a build system bug, causing an infinite l |
|
|
This can also happen (although we don't know precisely why) if you modify something in a built tree, and then re-run `make`. In this case the error is just overly conservative, and restarting is the right workaround.
|
|
|
|
|
|
|
|
|
It can also happen if you are building the sources on FreeBSD in a really fast environment, e.g. on a multi-core Xeon with multiple parallel threads (`make -j`) or a memory-backed file system (`mfs`, `tmpfs`) (see [\#7592](https://gitlab.haskell.org//ghc/ghc/issues/7592)). It is because precision of file timestamps is not fine-grained enough by default (due to the common VFS layer). You can change this granularity by adjusting the value of the `vfs.timestamp_precision` sysctl(3) variable (`sudo sysctl -w vfs.timestamp_precision=1`).
|
|
|
It can also happen if you are building the sources on FreeBSD in a really fast environment, e.g. on a multi-core Xeon with multiple parallel threads (`make -j`) or a memory-backed file system (`mfs`, `tmpfs`) (see [\#7592](https://gitlab.haskell.org/ghc/ghc/issues/7592)). It is because precision of file timestamps is not fine-grained enough by default (due to the common VFS layer). You can change this granularity by adjusting the value of the `vfs.timestamp_precision` sysctl(3) variable (`sudo sysctl -w vfs.timestamp_precision=1`).
|
|
|
|
|
|
|
|
|
If you encounter this without touching any files after typing 'make', then it's probably a bug in the build system. The `make -d` output will be useful in tracking it down, but depending on when it happens there might be a lot of it!
|
... | ... | @@ -76,7 +76,7 @@ tar (GNU tar) 1.19.90 |
|
|
```
|
|
|
|
|
|
|
|
|
I fixed this by downloading an up-to-date `tar`, from [ http://sourceforge.net/projects/mingw/files/](http://sourceforge.net/projects/mingw/files/). I put this `tar.exe` in `c:/msys/1.0/bin`, overwriting the old `tar.exe`. This works:
|
|
|
I fixed this by downloading an up-to-date `tar`, from [http://sourceforge.net/projects/mingw/files/](http://sourceforge.net/projects/mingw/files/). I put this `tar.exe` in `c:/msys/1.0/bin`, overwriting the old `tar.exe`. This works:
|
|
|
|
|
|
```wiki
|
|
|
sh-3.1$ tar cf foo.tar mk
|
... | ... | @@ -143,7 +143,7 @@ rm libraries/*/*/doc/*/*/*.haddock |
|
|
|
|
|
### ar: Bad file number
|
|
|
|
|
|
**Fixed in 6.12.1**. See [\#3201](https://gitlab.haskell.org//ghc/ghc/issues/3201). Workaround: add `SplitObjs=NO` to `mk/build.mk`.
|
|
|
**Fixed in 6.12.1**. See [\#3201](https://gitlab.haskell.org/ghc/ghc/issues/3201). Workaround: add `SplitObjs=NO` to `mk/build.mk`.
|
|
|
|
|
|
### chr: bad argument
|
|
|
|
... | ... | @@ -209,7 +209,7 @@ A dialog pops up: “Reflect_hsc_make.exe has stopped working”, with the butto |
|
|
|
|
|
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](http://www.haskell.org/pipermail/glasgow-haskell-bugs/2009-April/018643.html). We wish we knew why!
|
|
|
See [Sigbjorn's email](http://www.haskell.org/pipermail/glasgow-haskell-bugs/2009-April/018643.html). 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`:
|
... | ... | @@ -469,7 +469,7 @@ then you have probably not got `automake` installed (or at least findable). |
|
|
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](https://gitlab.haskell.org//ghc/ghc/issues/1271)), so if you're using that version or later you shouldn't encounter this issue.
|
|
|
We added a workaround for install-detection in GHC 6.8.1 (see [\#1271](https://gitlab.haskell.org/ghc/ghc/issues/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
|
|
|
|
... | ... | @@ -499,7 +499,7 @@ make: *** [all] Error 1 |
|
|
### 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](http://wiki.ubuntu.com/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.
|
|
|
In Ubuntu 6.10 the default system shell `/bin/sh` was changed to `dash` (The Debian Almquist Shell) instead of `bash`, see [DashAsBinSh](http://wiki.ubuntu.com/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.
|
|
|
|
|
|
### c:\\msys\\1.0\\bin\\make.exe: **\* couldn't commit memory for cygwin heap, Win32 error 0**
|
|
|
|
... | ... | @@ -550,4 +550,4 @@ If you've installed gmp from source on your Mac OS machine, you may see an error |
|
|
```
|
|
|
|
|
|
|
|
|
The problem is described [ on this page](https://github.com/mxcl/homebrew/issues/12946), a quick work-around is to install gmp with homebrew, i.e. `brew install gmp; brew link gmp`. |
|
|
The problem is described [on this page](https://github.com/mxcl/homebrew/issues/12946), a quick work-around is to install gmp with homebrew, i.e. `brew install gmp; brew link gmp`. |