Changes between Version 1 and Version 2 of Building/Troubleshooting


Ignore:
Timestamp:
Mar 10, 2009 12:03:49 PM (6 years ago)
Author:
simonmar
Comment:

Moving FAQ to here

Legend:

Unmodified
Added
Removed
Modified
  • Building/Troubleshooting

    v1 v2  
    4141(Incidentally, `find` is another program that Windows has too, with different functionality to Unix.)
    4242
    43 === Aregument list too long ===
     43=== Argument list too long ===
    4444
    4545You may find this towards the end of compiling the base library:
     
    7070
    7171Note, that it's not good to edit `target.mk` in general.
     72
     73=== Space in TMPDIR ===
     74
     75One difficulty that comes up from time to time is running out of space
     76in {{{TMPDIR}}}.  (It is impossible for the configuration stuff to
     77compensate for the vagaries of different sysadmin approaches to temp
     78space.)
     79
     80The quickest way around it is {{{setenv TMPDIR /usr/tmp}}} or
     81even {{{setenv TMPDIR .}}} (or the equivalent incantation with your shell
     82of choice).
     83
     84The best way around it is to say
     85{{{
     86export TMPDIR=<dir>
     87}}}
     88in your {{{build.mk}}} file.  Then GHC and the other
     89tools will use the appropriate directory in all cases.
     90
     91
     92=== Warning "warning: assignment from incompatible pointer type" ===
     93
     94You may occasionally see a warning from the C compiler when compiling some
     95Haskell code, eg. "warning: assignment from
     96incompatible pointer type".  These are usually harmless, but it's a good idea to
     97report it on the mailing list so that we can fix it.
     98
     99=== Warning "ar: filename `GlaIOMonad__1_2s.o` truncated to `GlaIOMonad_`" ===
     100
     101Similarly, {{{ar}}}chiving warning messages like the following are not a problem:
     102{{{
     103ar: filename GlaIOMonad__1_2s.o truncated to GlaIOMonad_
     104ar: filename GlaIOMonad__2_2s.o truncated to GlaIOMonad_
     105...
     106}}}
     107
     108=== Cpp variations ===
     109
     110GHC's sources go through {{{cpp}}} before being compiled, and {{{cpp}}} varies
     111a bit from one Unix to another.  One particular gotcha is macro calls
     112like this:
     113{{{
     114SLIT("Hello, world")
     115}}}
     116Some {{{cpp}}}s treat the comma inside the string as separating two macro
     117arguments, so you get
     118{{{
     119:731: macro `SLIT' used with too many (2) args
     120}}}
     121Alas, {{{cpp}}} doesn't tell you the offending file!
     122Workaround: don't put weird things in string args to {{{cpp}}} macros.
     123
     124
     125=== Cabal/Distribution/Compat/FilePath.hs: No such file or directory ===
     126
     127You may see this:
     128  {{{
     129Distribution/Compat/FilePath.hs:2:
     130  error: Cabal/Distribution/Compat/FilePath.hs: No such file or directory
     131make[1]: *** [depend] Error 1
     132make: *** [stage1] Error 1
     133  }}}
     134'''Possible Solution'''::
     135Be 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.
     136
     137=== xargs: /usr/bin/ar: terminated by signal 11 ===
     138
     139You may see this when compiling libraries:
     140{{{
     141(echo Control/Concurrent_stub.o System/CPUTime_hsc.o System/Time_hsc.o ;
     142/usr/bin/find Control/Applicative_split Control/Arrow_split
     143Control/Concurrent_split Control/Concurrent/Chan_split
     144   ...long mess...
     145Text/PrettyPrint/HughesPJ_split Text/Printf_split Text/Read_split
     146Text/Read/Lex_split Text/Show_split Text/Show/Functions_split -name '*.o'
     147-print) | xargs /usr/bin/ar q libHSbase.a
     148/usr/bin/ar: creating libHSbase.a
     149xargs: /usr/bin/ar: terminated by signal 11
     150make[2]: *** [libHSbase.a] Error 125
     151make[2]: *** Deleting file `libHSbase.a'
     152make[1]: *** [all] Error 1
     153}}}
     154What is happening is that the ghc build system is linking thousands and
     155thousands of tiny .o files into `libHSbase.a`. GNU `ar` isn't optimised for
     156this use-case and it takes far more memory than it really needs to. So
     157what happens is that ar takes >500Mb of memory and your virtual
     158machine / virtual server probably isn't configured with that much memory
     159and so the linux kernel OOM killer terminates the ar process.
     160
     161To make this worse, since there are so many .o files, it takes several
     162invocations of ar to link them all. On each invocation `ar` is building
     163the symbol index (-q is ignored) and this is what takes the most time
     164and memory. It's a good deal quicker to use a custom program (100 lines
     165of Haskell) to build `libHSbase.a` and then use `ranlib` just once to build
     166the symbol index.
     167
     168[Duncan Coutts] I submitted a patch to gnu `binutils` to make ar take less memory when
     169linking 1000's of files so it now only takes around 100Mb rather than
     170500Mb when linking `libHSbase.a`. That patch is included in version 2.17 I
     171think (in other words most systems don't have it yet).
     172
     173What you can do in the mean time is either configure your virtual
     174machine with more memory or turn off the split-objs feature when you
     175configure ghc. Just add `SplitObjs=NO` to your `mk/build.mk` file (which
     176may not exist to start with). (The Gentoo ebuild does this
     177automatically)
     178