I wrote:
I have a program (no doubt pretty grotty - I'm still messing around
learning Haskell) which causes GHC (4.04.19990916) to produce an
executable which coredumps.
...
I'm using a GHC binary package from Debian GNU/Linux, binary package
version 4.04.19990916-0slink1 built by Michael
Michael and I worked out a way for coping with this phenomenon while it lasts,
(even if this is now fixed for most cases except interruption, I still haven't
managed to get a new ghc going due to the CVS woes :|),
so if anyone is interested, instructions follow:
Write yourself a small C-program
Simon Marlow [EMAIL PROTECTED] wrote,
I think there is still a problem with non-blocking I/O
hosing some shells on abnormal program termination. This is
on Linux, using bash and the latest sources from CVS.
Yep, you're probably right. I think I'm going to back off on this one and
Sven Panne [EMAIL PROTECTED] wrote,
It works if the two spaces after -#include are replaced by a single
space, but the "real" Haskell sources are created by Green Card, so
I can't change that easily.
Come one, Sven, this is an _absolutely_ lame excuse: if you
are running cpp over your
Ian Jackson [EMAIL PROTECTED] wrote,
I wrote:
I have a program (no doubt pretty grotty - I'm still messing around
learning Haskell) which causes GHC (4.04.19990916) to produce an
executable which coredumps.
...
I'm using a GHC binary package from Debian GNU/Linux, binary package
I've been trying literally a dozen times to build a GHC from CVS, but
have not yet succeeded. The problem is to find a "right"
compiler which
runs on my SuSE 6.2 system *and* compiles the sources. I won't go into
the very sad and depressing details here, so my question simply is:
Has
This is the same problem as Ian Jackson's. Take a look at my response in
the other thread ("GHC 4.04.19990916 produces coredumping executable").
Cheers,
Simon
I think there is still a problem with non-blocking I/O
hosing some shells on abnormal program termination. This is
on Linux, using bash and the latest sources from CVS.
Yep, you're probably right. I think I'm going to back off on this one and
not set the non-blocking flag on stdout and
| ---
| make Main.o; make run; ./run
| reports: "... no threads to run. Dead lock? "
This is a very awkward but well known bug concerning locking
of file handles. But we are guilty of not advertising it
Thanks for reporting this. Simon M says it's a well known
bug that cross-module exporting of existential things is broken,
but I'd completely forgotten about it. Anyway I've checked
in a fix. See if it works now.
Simon
| -Original Message-
| From: Manuel M. T. Chakravarty
Simon Marlow [EMAIL PROTECTED] wrote,
for future distributions, I'll switch back to supplying our own
statically-linked libgmp.a for Linux, I think.
This is not required for package-manager managed binaries
for systems that have a package containing `libgmp.so' (like
RedHat, but not SuSE).
[...]
-davenant:stalk ./nettlestalk
foo
Segmentation fault (core dumped)
I'm using 4.04.19990916-2 and it doesn't coredump, but shows the same
deadlock error, you mentioned in the other mail:
[509]$ ./nettlestalk
foo
nettlestalk: fatal error: No threads to run! Deadlock?
This
12 matches
Mail list logo
