Changes between Version 1 and Version 2 of Building/Troubleshooting

Mar 10, 2009 12:03:49 PM (7 years ago)

Moving FAQ to here


  • Building/Troubleshooting

    v1 v2  
    4141(Incidentally, `find` is another program that Windows has too, with different functionality to Unix.)
    43 === Aregument list too long ===
     43=== Argument list too long ===
    4545You may find this towards the end of compiling the base library:
    7171Note, that it's not good to edit `` in general.
     73=== Space in TMPDIR ===
     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
     80The quickest way around it is {{{setenv TMPDIR /usr/tmp}}} or
     81even {{{setenv TMPDIR .}}} (or the equivalent incantation with your shell
     82of choice).
     84The best way around it is to say
     86export TMPDIR=<dir>
     88in your {{{}}} file.  Then GHC and the other
     89tools will use the appropriate directory in all cases.
     92=== Warning "warning: assignment from incompatible pointer type" ===
     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.
     99=== Warning "ar: filename `GlaIOMonad__1_2s.o` truncated to `GlaIOMonad_`" ===
     101Similarly, {{{ar}}}chiving warning messages like the following are not a problem:
     103ar: filename GlaIOMonad__1_2s.o truncated to GlaIOMonad_
     104ar: filename GlaIOMonad__2_2s.o truncated to GlaIOMonad_
     108=== Cpp variations ===
     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:
     114SLIT("Hello, world")
     116Some {{{cpp}}}s treat the comma inside the string as separating two macro
     117arguments, so you get
     119:731: macro `SLIT' used with too many (2) args
     121Alas, {{{cpp}}} doesn't tell you the offending file!
     122Workaround: don't put weird things in string args to {{{cpp}}} macros.
     125=== Cabal/Distribution/Compat/FilePath.hs: No such file or directory ===
     127You may see this:
     128  {{{
     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.
     137=== xargs: /usr/bin/ar: terminated by signal 11 ===
     139You may see this when compiling libraries:
     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
     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.
     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.
     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).
     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/` file (which
     176may not exist to start with). (The Gentoo ebuild does this