RE: Cannot build 5.02.2 on Solaris 2.7
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
multiple methods pattern bug(?)
Hi,
the following instance declaration doesn't work any
more with ghc-5.02.3, it worked before.
newtype ST state a = ST { unST :: state - (a,state) }
instance Monad (ST c) where
return x = ST (\state - (x,state))
(m = f) = ST (\state - let (x,state1) = unST m state
(y,state2) = unST (f x) state1
in (y,state2))
Error message:
Can't handle multiple methods defined by one pattern binding
(m = f)
= ST (\ state
- let
(y, state2) = ...
(x, state1) = ...
in (y, state2))
What can I do instead?
--
Christoph
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: multiple methods pattern bug(?)
the following instance declaration doesn't work any
more with ghc-5.02.3, it worked before.
newtype ST state a = ST { unST :: state - (a,state) }
instance Monad (ST c) where
return x = ST (\state - (x,state))
(m = f) = ST (\state - let (x,state1) = unST m state
(y,state2) = unST (f x) state1
in (y,state2))
Error message:
Can't handle multiple methods defined by one pattern binding
(m = f)
= ST (\ state
- let
(y, state2) = ...
(x, state1) = ...
in (y, state2))
What can I do instead?
Remove the parentheses on the left hand side - that's not legal Haskell
98. The error message is a bit cryptic though, the renamer should
really spot that it isn't a valid pattern binding first.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Panic loading objects with big strings in Windows
With ghc-5.02.3 on Windows starting with a package containing an object with a large String I get the following message. Note the last line. ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.02.3, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package util ... linking ... done. Loading package data ... linking ... done. Loading package text ... linking ... done. Loading package uni-options ... linking ... done. Loading package uni-util ... linking ... done. Loading package uni-events ... linking ... done. Loading package uni-reactor ... linking ... done. Loading package uni-htk ... ghc.exe: panic! (the `impossible' happened, GHC version 5.02.3): loadObj: failed Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. PEi386 object has suspiciously large string table; 64k relocs? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Cannot build 5.02.2 on Solaris 2.7
Simon Marlow wrote: $ 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? I wish I could, but I am tied in using a much larger set of tools with many other people running Solaris 2.5.1, 2.7, and 2.8. So far we have not found any problems running those 2.5.1 compiled tools on any of our systems. But, as you said, there is always a chance and I will keep it in mind. 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? Yes 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). I ran into the problem using 5.02.1 binaries, upgrading to 5.02.2 did not help. 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 grabed the failing invocation and added +RTS -H10m, and then -H20m. All invocations fail the same way. 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. Using gdb, I found that the core was from a perl invocation. Using -v3 I found ghc-split to dump core. : *** Splitter /home/dorr/func/haskell/sources/ghc-5.02.2/ghc/driver/split/ghc-split /tmp/ghc21821.split_s /tmp/ghc21821.split /tmp/ghc21821.split Bus Error - core dumped : How can I preserve the tmp files, so I can debug the perl run? I don't know anything about what split is supposed to achieve. Where should I read up on this? Martin ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
