Changes between Version 32 and Version 33 of Building/Troubleshooting


Ignore:
Timestamp:
May 4, 2011 10:34:44 PM (4 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 "[email protected];c:\\msys\\1.0\\home\\darcs\\ghc" ==
    75 
    76 On Windows under MSYS, suppose your `_darcs/pref/defaultrepo` contains `[email protected]:/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 . [email protected]:/home/darcs/ghc
    80 No remote changes to pull in!
    81 == running darcs pull --repodir utils/hsc2hs [email protected]:/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 [email protected];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 . [email protected];c:\msys\1.0\home\darcs\ghc/ghc
    95 No remote changes to pull in!
    96 == running darcs pull --repodir utils/hsc2hs [email protected];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 "[email protected];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.