... | ... | @@ -51,7 +51,7 @@ Solution: either hack the configure script by hand, or (better) make sure that M |
|
|
|
|
|
(Incidentally, `find` is another program that Windows has too, with different functionality to Unix.)
|
|
|
|
|
|
### Aregument list too long
|
|
|
### Argument list too long
|
|
|
|
|
|
|
|
|
You may find this towards the end of compiling the base library:
|
... | ... | @@ -92,3 +92,133 @@ where NNN is the number of arguments processed at a time. It should be small eno |
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
```wiki
|
|
|
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, `ar`chiving warning messages like the following are not a problem:
|
|
|
|
|
|
```wiki
|
|
|
ar: filename GlaIOMonad__1_2s.o truncated to GlaIOMonad_
|
|
|
ar: filename GlaIOMonad__2_2s.o truncated to GlaIOMonad_
|
|
|
...
|
|
|
```
|
|
|
|
|
|
### Cpp variations
|
|
|
|
|
|
|
|
|
GHC's sources go through `cpp` before being compiled, and `cpp` varies
|
|
|
a bit from one Unix to another. One particular gotcha is macro calls
|
|
|
like this:
|
|
|
|
|
|
```wiki
|
|
|
SLIT("Hello, world")
|
|
|
```
|
|
|
|
|
|
|
|
|
Some `cpp`s treat the comma inside the string as separating two macro
|
|
|
arguments, so you get
|
|
|
|
|
|
```wiki
|
|
|
:731: macro `SLIT' used with too many (2) args
|
|
|
```
|
|
|
|
|
|
|
|
|
Alas, `cpp` doesn't tell you the offending file!
|
|
|
Workaround: don't put weird things in string args to `cpp` macros.
|
|
|
|
|
|
### Cabal/Distribution/Compat/FilePath.hs: No such file or directory
|
|
|
|
|
|
|
|
|
You may see this:
|
|
|
|
|
|
```wiki
|
|
|
Distribution/Compat/FilePath.hs:2:
|
|
|
error: Cabal/Distribution/Compat/FilePath.hs: No such file or directory
|
|
|
make[1]: *** [depend] Error 1
|
|
|
make: *** [stage1] Error 1
|
|
|
```
|
|
|
|
|
|
**Possible Solution**::
|
|
|
Be sure you have run `sh darcs-all get` to get all necessary packages. Don't forget to run `sh boot` again after you pull in new packages.
|
|
|
|
|
|
### xargs: /usr/bin/ar: terminated by signal 11
|
|
|
|
|
|
|
|
|
You may see this when compiling libraries:
|
|
|
|
|
|
```wiki
|
|
|
(echo Control/Concurrent_stub.o System/CPUTime_hsc.o System/Time_hsc.o ;
|
|
|
/usr/bin/find Control/Applicative_split Control/Arrow_split
|
|
|
Control/Concurrent_split Control/Concurrent/Chan_split
|
|
|
...long mess...
|
|
|
Text/PrettyPrint/HughesPJ_split Text/Printf_split Text/Read_split
|
|
|
Text/Read/Lex_split Text/Show_split Text/Show/Functions_split -name '*.o'
|
|
|
-print) | xargs /usr/bin/ar q libHSbase.a
|
|
|
/usr/bin/ar: creating libHSbase.a
|
|
|
xargs: /usr/bin/ar: terminated by signal 11
|
|
|
make[2]: *** [libHSbase.a] Error 125
|
|
|
make[2]: *** Deleting file `libHSbase.a'
|
|
|
make[1]: *** [all] Error 1
|
|
|
```
|
|
|
|
|
|
|
|
|
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) |