Simon Marlow wrote:
> Our nightly build did a two-stage bootstrap last night on a Sparc/Solaris
> system successfully
>
> ~/builds > uname -a
> SunOS gigha 5.7 Generic_106541-04 sun4u sparc SUNW,Ultra-5_10
uname -a
SunOS titania 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-1
> ~/builds > gcc -v
> Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
gcc -v
Reading specs from /usr/local/lang/gnu/lib/gcc-lib/sparcv9-sun-solaris2.7/2.95.2/specs
gcc version 2.95.2 19991024 (release)
>
> Stage 1 was build with 4.04pl1 (make sure you have pl1!), and stage 2 was
cksum ghc-4.04-sparc-sun-solaris2.tar.gz
2269644928 6114825 ghc-4.04-sparc-sun-solaris2.tar.gz
> bootstrapped. I've just done a stage 3 build too, which went through
> without a hitch.
Was the stage 2 build installed in a separate directory as it was here, or
eas it in place?
>
> So I'm at a loss now: Marc reported that downgrading his gcc fixed the
> problem. That suggests that it's a gcc bug, but we're using 2.95.2 here
> without any difficulties.
>
> There's also the outstanding build problem related to sigset_t, which I also
> can't reproduce.
>
> Any insight appreciated.
OK, after hacking ghc-inplace to stop it deleting all its files (is there
a --keep-everything option?) and running hsc inside gdb I get:
Glasgow Haskell Compiler, version 4.06, for Haskell 98, compiled by GHC version 4.06
Program received signal SIGSEGV, Segmentation fault.
0x90062010 in ?? ()
(gdb) bt
#0 0x90062010 in ?? ()
#1 0xa7db74 in schedule ()
#2 0xa7e080 in waitThread ()
#3 0xa7c8a8 in rts_evalIO ()
#4 0xa7c2b8 in main ()
I'll keep the gdb session alive for the rest of today if you have any more
queries.
