Changes between Version 1 and Version 2 of Building/Troubleshooting

Mar 10, 2009 12:03:49 PM (6 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