Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/simonmar/nightly/HEAD
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Sat Dec 12 18:00:01 GMT 2009.
checking out
Build description = HEAD on x86_64-unknown-linux
(cam-04-unx.europe.corp.microsoft.com)
Build location= /64playpen/simonmar/nightly/HEAD-cam-04-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-04-unx
Nightly build started on cam-04-unx at Sat Dec 12 19:00:01 GMT 2009.
**
As this patch adds platform-specific code to the build system and runtime
system, I validated on Linux (Debian) and on Mac OS X (10.5 and 10.6). I
couldn't easily validate on Windows; so, please let me know if there are any
problems with this (the current failure reporting that gmp.h cannot be
Sat Dec 12 02:08:09 PST 2009 Manuel M T Chakravarty
* Expose all EventLog events as DTrace probes
Ignore-this: 2c5ef30b1ff7fb2ea5fba8cf0a187d45
- Defines a DTrace provider, called 'HaskellEvent', that provides a probe
for every event of the eventlog framework.
- In contrast to the ori
BTW, windows buildbots fall over in the same way:
http://darcs.haskell.org/buildbot/all/builders/x86%20Windows%20head%20fast/builds/4977/steps/compile/logs/stdio
And it also happens with just one make thread, although it seems to succeed
sometime, I see more failure than successful builds.
Manu
Actually, it sometimes also happens with 4 cores (and maybe less?) and I also
sometimes get
> config.status: executing src commands
> # libffi.so needs to be built with the correct soname.
> # NOTE: this builds libffi_convience.so with the incorrect
> # soname, but we don't need that anyway!
> cd
Build results:
x86-64 Linux head: lost
x86 Windows head:fail (failed compile)
x86 Windows head fast: fail (failed compile) fail (failed compile) fail
(failed compile) fail (failed darcs) fail (failed compile) fail (failed compile)
x86-64 Linux head unreg: lost
Dropping unexpected
Build results:
bitslayer stable:fail (failed configure)
tnaur PPC OSX stable 2: fail (failed compile)
tnaur x86 OS X stable: pass
x86 Linux stable:lost
x86 Windows stable: pass
x86 Windows stable fast: pass pass lost pass fail (failed darcs) pass
x86-64 Linux stable: lo
I think this is since the new c_asm.bit dependency stuff was introduced. The
problem only seems to happen in a very parallel build, and my guess is that
this happens on any box that doesn't have gmp.h globally installed.
I ran into it when using 8 cores (with 'env CPUS=8 sh validate'):
> /usr/