>> Perhaps someone who knows SELinux would like to describe how to
set up
>> an exception for GHC so we can put it in the FAQ?
I have added:
/usr/bin/chcon -t unconfined_execmem_exec_t /path/to/binary/prog
to the %post install scripts of the darcs and haddock packages in
Fedora Extras for n
Simon Marlow wrote:
My fix works around allow_execheap being set to 0, but not
allow_execmem. This page describes how to work around allow_execmem:
http://people.redhat.com/drepper/selinux-mem.html
Okay, thanks.
But I really object to having to go to such lengths just to work around
an o
Jon Fairbairn wrote:
Fixed in the HEAD and the 6.4 branch, but I haven't been able to test
(don't have SE Linux on a local machine). Please download a snapshot and
try it out, if possible.
That does seem to mend it for me. Note that my report says
it only seems to happen x86_64 while in fa
Johan van der Teems wrote:
> Linux ollie 2.6.10-5-amd64-k8 #1 Fri Jun 24 17:08:40 UTC 2005 x86_64 GNU/Linux
> c2hsLocal: internal error: scavenge_mark_stack: unimplemented/strange closure
> type -1780771344 @ 0x2a95db9058
> Please report this as a bug to glasgow-haskell-bugs@haskell.org,
>
Hi,
I built and installed wxhaskell-0.9 with ghc-6.2.2 on x86_64.
When I link a sample program and try to run it however,
I get:
wxhaskell-0.9/samples/wx% ./a.out
a.out: internal error: adjustor creation not supported on this platform
Please report this as a bug to glasgow-haskell-bugs@haskell.
2003年06月04日(水)の17時33分に Jens Petersen 曰く:
> Thanks! I made an rpm package of it with ghc-6.0 built for Red Hat Linux
> 9:
>
> http://haskell.org/~petersen/rpms/greencard/greencard-3.00-1.src.rpm
> http://haskell.org/~petersen/rpms/greencard/greencard-ghc6.0-3.00-1.rhl9.i386.rpm
S
2003年06月03日(火)の04時59分に Alastair Reid 曰く:
> On Monday 02 June 2003 7:20 pm, Alastair Reid wrote:
>
> > In preparation for a major release of Green Card, we are making an alpha
> > release for GHC folk to play with.
Thanks! I made an rpm package of it with ghc-6.0 built for Red Hat Linux
9:
http:/
Jens Petersen <[EMAIL PROTECTED]> writes:
> Jens Petersen <[EMAIL PROTECTED]> writes:
>
> > It would be good if ghc would at like give a better error
> > message when an empty cmd is passed to -pgmX.
>
> Rather I think it should abort rather than fork
Jens Petersen <[EMAIL PROTECTED]> writes:
> It would be good if ghc would at like give a better error
> message when an empty cmd is passed to -pgmX.
Rather I think it should abort rather than forking an empty
command...
Jens
___
Glasgow-
Not sure whether this is a documentation bug or not, but I
got tripped over by the syntax of the -pgm options this
week.
In the user-guide
http://haskell.org/ghc/docs/latest/set/flag-reference.html#AEN5804
there clearly seem to be spaces between -pgmX and cmd,
however looking at the code in
ghc/c
"Simon Marlow" <[EMAIL PROTECTED]> writes:
>> /tmp/ghc19742.hc:4928: Unable to find a register to spill in
>> class `SIREG'.
>> /tmp/ghc19742.hc:4928: confused by earlier errors, bailing out
>> make: *** [examples/Libgr.o] error 1
>
> This is an error from the C compiler telling you it ran out
While trying to compile qforeign cvs with ghc-5.02.1, I get
the following error.
/usr/bin/ghc -c -O -Wall -fglasgow-exts -package lang -package data -package
concurrent -package posix -iexamples -ilib -Iexamples -Ilib examples/Libgr_hsc.c
programs/hsc2hs-inplace --cc=/usr/bin/ghc -I. -Iexamp
Pixel <[EMAIL PROTECTED]> writes:
> Jens Petersen <[EMAIL PROTECTED]> writes:
>
>> I'm surprised you can't reproduce it. Are you configuring the RTS
>> differently from the default?
>
> you tested with ghc-5.00.2-1, try ghc-5.02?
Oops, you
"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> writes:
> 05 Oct 2001 17:51:45 +0900, Jens Petersen <[EMAIL PROTECTED]> pisze:
>
>> IMHO hugs is doing the right thing here. Shouldn't ghc also
>> close semiclosed handles when all referen
Pixel <[EMAIL PROTECTED]> writes:
> Malcolm Wallace <[EMAIL PROTECTED]> writes:
>
>> It is really a question of when the garbage collector runs.
>> Your example program is very small, so the GC does not run (and
>> therefore does not collect the unused handles) before the open file
>> table is f
I don't think this is new, but I feel it is a ghc bug.
Please correct me if I'm wrong. I do:
% cat > manyfiles.hs
main :: IO ()
main =
do
readFile "manyfiles.hs"
main
% ghc -o manyfiles manyfiles.hs
% ./manyfiles
Fail: resource exhausted
Action: openFile
Reason: process file table
16 matches
Mail list logo
