> > I've just finished building 5.02.3 on sparc-solaris, and
> didn't get any
> > core dumps, so there must be something different about your
> setup. What
> > version of
> > gcc are you using? What version of GHC are you bootstrapping with?
>
> $ gcc -v
> Reading specs from .../gcc-lib/sparc-sun-solaris2.5.1/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
I don't know if this is relevant, but the above gcc looks like it was
built on Solaris 2.5, but you're on a 2.7 system. Perhaps rebuild gcc
to be on the safe side?
> For GHC I tried 5.02.1 and 5.02.2 binaries for solaris. The
> core dump due
> to bus error occurs when building from 5.02.2 AND 5.02.3
> sources. It did
> not occur when building from 5.02.1 sources and setting
> GhcRtsHcOpts = -optc-DDEBUG -optc-g -keep-hc-file
> GhcRtsCcOpts = -g
> in mk/build.mk. I don't know whether the default build
> components have
> changed from 5.02.1 to 5.02.2, and Monad.p_o was never built
> (I have no
> make log from that build and had to remove the source tree to
> make room
> for the 5.02.2 source).
Just so I'm clear on what we're actually examining here: this is the
5.02.2 sources built using the 5.02.2 binary distribution, right?
You're not using 5.02.1 to build with? (it'll be easier to track down
if we're bootstrapping 5.02.2 with itself).
Could you try changing the heap size when running the offending
compilation and see if the core dump goes away? If it doesn't vary with
the heap size, then it is probably much easier to track down because it
won't be GC-related.
> I tried looking at the core dump with ddd, but it got an
> internal bus error
> while loading the the core file.
gdb shouldn't crash (I hope). If it does, we're up the creek.
> Better as in simpler, or really better?
There are a few settings which *must* be set using ./configure,
everything else should be set in build.mk. The ones that must be set
with configure are exactly those options which configure accepts -
prefix, with-gcc, with-ghc, etc. It might be possible to set some of
these in build.mk, but it's asking for trouble. The reason is that the
configure script uses some of these settings to derive other settings,
and if you set them in build.mk then the derived settings will be wrong.
> After a default
> build works, I need
> to set GhcRtsHcOpts, GhcRtsCcOpts, and potentially other parameters.
> Shouldn't I just start a build.mk anyway rather then pass all
> of these into
> ./configure? Are there guidelines on when to define parameters via
> ./configure options versus build.mk?
Yes, by all means have a build.mk as well.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
