Bcc: Re: bizzare compilation problem

[Manuel M. T. Chakravarty]

---

Peter Amstutz <[EMAIL PROTECTED]> wrote,

> Alright, I'm _still_ trying to get a working 4.03 compiler so I can play
> with the FFI...  So far I've got the ghc 4.02 linux distribution working
> fine.  A couple weeks ago I tried out the cvs source and was stopped by a
> typo.  Someone reccomended a binary, but it didn't work (strange linking
> errors...)  So now I'm back to trying to compile again, with sources
> updating as of about five minutes ago.  I'm getting this *strange*
> problem:
> 
[...]
> Everything up to here compiles fine, but on this file something fucks up.
> Basically it just sits here and *grinds*, in a matter of seconds gobbling
> up something like 70 or 80 megabytes of memory (my system only has 64!)
> and pretty much just sitting there doing nothing (I let it sit for
> somthing like 15 minutes trying to build this one file and it never got
> anywhere, so I finally ^C'd it...  yes I have tried to build it several
> times, with exactly the same effect)

The appended message may be of some help.  Anyway, compiling
ParseIFace takes an awfully lot of memory and even more
time.  (The 72Mb heap suggested in the appended message may
even be to small!)  The compile can take really long,
especially if you don't have enough physical memory, don't
be surprised if it takes 15 or 30min.

I think, it is really time for an official release of GHC
with a working FFI...(I now everybody is working hard, but
the FFI stuff seems to bother quite a few people.)

Cheers,

Manuel

PS: Depending on what you want to do with the FFI, GHC 4.02
    might actually be sufficient (at least to start with
    coding).  The FFI in 4.02 works most of the time, so if
    you don't plan to do exotic things with it, it might be
    easier to use 4.02 for a while and wait until a new
    release is out before upgrading - I am very sure about
    this, as I am using the FFI of 4.02 myself (see
    http://www.score.is.tsukuba.ac.jp/~chak/haskell/gtk/).

-------------------------------------------------------------------------
Message-ID: <4FD6422BE942D111908D00805F3158DF0F49CC07@RED-MSG-52>
Sender: [EMAIL PROTECTED]
Resent-Date:  Wed, 3 Feb 1999 10:32:08 +0000
Subject: RE: Increasing max. heap size during compilation
From: "Sigbjorn Finne (Intl Vendor)" <[EMAIL PROTECTED]>
To: "'Frank A. Christoph'" <[EMAIL PROTECTED]>
Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Date: Wed, 3 Feb 1999 02:31:37 -0800 
Resent-From: [EMAIL PROTECTED]
Resent-To: [EMAIL PROTECTED]
Old-Received: from mail2.microsoft.com by vanuata with SMTP (MMTA) with ESMTP; 
              Wed, 3 Feb 1999 10:31:51 +0000
Old-Received: by mail2.microsoft.com           with Internet Mail Service 
              (5.5.2524.0)      id <D8HB9C0T>;          Wed, 3 Feb 1999 02:31:43 
              -0800
X-Mailer: Internet Mail Service (5.5.2524.0)
Precedence: bulk


Frank A. Christoph <[EMAIL PROTECTED]> writes: 
> 
> Since the -M option has been co-opted for other purposes by 
> the ghc Perl startup script, and you can't pass explicit RTS 
> options to the compiler itself (why isn't this allowed?), 
> it's impossible to compile modules which need more than 64MB 
> of heap space. (64mb is the default maximum for the new 
> automated heap-growing.) For example, on my Linux 
> installation, ParseIFace.lhs needs something like 72MB to 
> compile, so I had to alter the startup script to pass an 
> extra -M72mb when compiling that file with the 4.02 compiler 
> itself.  (BTW, can we expect the compiler to be a less 
> memory-intensive when it is released?)
> 

Use -optCrts<option> to feed options to the RTS of the compiler,
i.e., -optCrts-M72M 

--Sigbjorn

---