Changes between Version 32 and Version 33 of Building/Troubleshooting


Ignore:
Timestamp:
May 4, 2011 10:34:44 PM (3 years ago)
Author:
dterei
Comment:

Remove some darcs specific workarounds.

Legend:

Unmodified
Added
Removed
Modified
  • Building/Troubleshooting

    v32 v33  
    6262On MSYS I got this: 
    6363{{{ 
    64 bash$ ./darcs-all get 
     64bash$ ./sync-all get 
    6565     ....snip... 
    6666== Syncing tarballs 
     
    7171}}} 
    7272This happened to me with an old version of the shell (say "sh --version").  I think perhaps the path-mangling is different.  With the MSYS recommended [wiki:Building/Preparation/Windows here], all is well.  The shell there is version 3.1.0(1). 
    73  
    74 == Pulling from "simonpj@darcs.haskell.org;c:\\msys\\1.0\\home\\darcs\\ghc" == 
    75  
    76 On Windows under MSYS, suppose your `_darcs/pref/defaultrepo` contains `simonpj@darcs.haskell.org:/home/darcs/ghc` (i.e. you are using an SSH connection). Then `darcs_all` will screw up:  
    77 {{{ 
    78 bash-3.1$ ./darcs-all pull 
    79 == running darcs pull --repodir . simonpj@darcs.haskell.org:/home/darcs/ghc 
    80 No remote changes to pull in! 
    81 == running darcs pull --repodir utils/hsc2hs simonpj@darcs.haskell.org:/home/darcs/hsc2hs 
    82 Reading inventory of repository c:/code/HEAD/utils/hsc2hs inventory 
    83 No remote changes to pull in! 
    84 ... 
    85 }}} 
    86 Looks ok, but look at the defaultrepo: 
    87 {{{ 
    88 bash-3.1$ cat _darcs/prefs/defaultrepo 
    89 simonpj@darcs.haskell.org;c:\msys\1.0\home\darcs\ghc/ghc 
    90 }}} 
    91 Glarp!  And indeed if you re-try the pull, bad things happen: 
    92 {{{ 
    93 ./darcs-all pull 
    94 == running darcs pull --repodir . simonpj@darcs.haskell.org;c:\msys\1.0\home\darcs\ghc/ghc 
    95 No remote changes to pull in! 
    96 == running darcs pull --repodir utils/hsc2hs simonpj@darcs.haskell.org;c:\msys\1.0\home\darcs\ghc/hsc2hs 
    97 ... 
    98 }}} 
    99 Since defaultrepo is hosed, plain darcs fails too: 
    100 {{{ 
    101 bash-3.1$ darcs pull 
    102 Pulling from "simonpj@darcs.haskell.org;c:\\msys\\1.0\\home\\darcs\\ghc"... 
    103 No remote changes to pull in! 
    104 }}} 
    105 This problem seems hard to fix, because it's a bug in MSYS's perl.  See #3499 for a workaround. 
    10673 
    10774== configure: error: C++ preprocessor "/lib/cpp" fails sanity check == 
     
    221188Solution: delete {{{configure}}} first. 
    222189 
    223 === Configure can't find darcs version === 
    224  
    225 When you run your configure script, it falls over with  
    226 {{{ 
    227 sh-2.04$ ./configure --with-gcc=c:/mingw/bin/gcc --with-ld=c:/mingw/bin/ld.exe --host=i386-unknown-mingw32 
    228 configure: WARNING: If you wanted to set the --build type, don't use --host. 
    229     If a cross compiler is detected then cross compile mode will be used. 
    230 checking for GHC version date... -nThe system cannot find the file specified. 
    231 configure: error: failed to detect version date: check that darcs is in your path 
    232 }}} 
    233 This error is nothing to do with `darcs`!  The darcs-version test in `configure` uses `sort`, and it is picking up the Windows sort (in `c:\windows\system32`) instead of the MSYS or Cygwin sort.   
    234  
    235 Solution: either hack the configure script by hand, or (better) make sure that MSYS/Cygwin are in your PATH before Windows. Since `c:\windows\system32` is, by default, in the System Environment Variable called PATH, and System Variables come first when searching for paths, you'll have to put MSYS/Cygwin bin directory in the System PATH, before `c:\windows\system32`. 
    236  
    237 (Incidentally, `find` is another program that Windows has too, with different functionality to Unix.) 
    238  
    239190=== Argument list too long === 
    240191 
     
    329280  }}} 
    330281'''Possible Solution''':: 
    331 Be sure you have run {{{sh darcs-all get}}} to get all necessary packages. Don't forget to run {{{perl boot}}} again after you pull in new packages. 
     282Be sure you have run {{{./sync-all get}}} to get all necessary packages. Don't forget to run {{{./boot}}} again after you pull in new packages. 
    332283 
    333284=== xargs: /usr/bin/ar: terminated by signal 11 === 
     
    438389}}} 
    439390 
    440 === getCurrentDirectory: resource exhausted (Too many open files) === 
    441  
    442 By default, Mac OS X limits the number of open files to 256.  This may cause problems when applying patches in step 3 of ''Getting a GHC source tree using darcs'' with darcs 1.0.9. 
    443  
    444 {{{ 
    445 $ darcs pull -a 
    446 Pulling from "http://darcs.haskell.org/ghc"... 
    447 This is the GHC darcs repository (HEAD branch) 
    448  
    449 For more information, visit the GHC developer wiki at 
    450   http://hackage.haskell.org/trac/ghc 
    451 ********************** 
    452 darcs: getCurrentDirectory: resource exhausted (Too many open files) 
    453 }}} 
    454  
    455 If this happens, try increasing the number of open files allowed by typing in {{{$ ulimit -n unlimited}}} and try pulling again.  If this fails, close all terminal windows, restart Terminal.app, and try again. 
    456  
    457 If this still doesn't work, try pulling 100 patches at a time using the {{{darcs pull}}} command (notice the lack of the {{{-a}}} flag).  Hold down 'y' until 100 or so patches are accepted, then hit 'd' to skip the rest; repeat until all patches are applied.  If this fails, try with less than 100 patches at a time (e.g., 50). 
    458  
    459 This issue has been reported as [http://bugs.darcs.net/issue560 issue 560] in the darcs bug tracking system. 
    460  
    461391=== Ubuntu: {{{dash}}} vs {{{bash}}} === 
    462392In Ubuntu 6.10 the default system shell {{{/bin/sh}}} was changed to {{{dash}}} (The Debian Almquist Shell) instead of {{{bash}}}, see [http://wiki.ubuntu.com/DashAsBinSh 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.