Re: newbie: building ghc
On Thu, 2006-03-16 at 13:22 -0500, Mark Greenbank wrote: > Hi DUncan, > > Thanks for the help. > > I've installed a ghc compiler on my Linux box in order to > cross-compile and I'm getting the following error. Any ideas? You'll have to be very specific about exactly what procedures you're following. Porting ghc to a new platform is a bit tricky and there are many ways it can go wrong, especially if one doesn't exactly follow the recommended procedures. So you're now doing what exactly? Building ghc on your linux box? Is that just an ordinary build (which should work fine) or are you using special config options etc. you're following these instructions? http://haskell.org/ghc/docs/6.4.1/html/building/sec-porting-ghc.html#unregisterised-porting What stage are you at? Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: newbie: building ghc
Hi DUncan, Thanks for the help. I've installed a ghc compiler on my Linux box in order to cross-compile and I'm getting the following error. Any ideas? Thanks, Mark /usr/bin/ghc -H16m -O -H32m -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm -Istage1 -DOMIT_NATIVE_CODEGEN -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -O -H16M '-#include "hschooks.h"' -i../lib/compat -ignore-package Cabal -c codeGen/SMRep.lhs -o stage1/codeGen/SMRep.o -ohi stage1/codeGen/SMRep.hi codeGen/SMRep.lhs:283:45: Not in scope: `sIZEOF_StgArrWords_NoHdr' codeGen/SMRep.lhs:286:45: Not in scope: `sIZEOF_StgMutArrPtrs_NoHdr' <> make[1]: *** [stage1/codeGen/SMRep.o] Error 1 make: *** [all] Error 1 On 3/15/06, Duncan Coutts <[EMAIL PROTECTED]> wrote: On Wed, 2006-03-15 at 17:22 -0500, Mark Greenbank wrote:> Hi,>> Sorry for the newbie question ... I'm trying to build the compiler and> I'm getting the following error:>> [EMAIL PROTECTED] ghc-6.4.1]# ./configure --prefix=/usr/pkg> checking build system type... i386-pc-solaris2.10> checking host system type... i386-pc-solaris2.10> checking target system type... i386-pc-solaris2.10> Canonicalised to: i386-unknown-solaris2 > checking for path to top of build tree... /usr/pkg/src/ghc-6.4.1> checking for ghc... no> checking for nhc... no> checking for nhc98... no> checking for hbc... no> configure: error: GHC is required unless bootstrapping from .hc files. >> Does this somehow mean that I need the compiler in order to build the> compiler?Generally yes.You should start with a binary version of ghc and if you like you canthen use that to rebuild from source (or to build a newer version). This is how it works with most of the source based distros (eg Gentoo,FreeBSD). Another possibility is to boot from .hc files but if there isa binary available for your platform then that's the easiest method. I see you're using Solaris on x86. I recall someone on this list havinggot it bootstrapped before. If no one does have a build available thenyou'll need to follow these porting instructions: http://haskell.org/ghc/docs/6.4.1/html/building/sec-porting-ghc.html#sec-booting-from-hcIt should be possible to make it work since there are builds for Solarison sparc and for other OSs on x86 and x86_64. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mixing registerised and unregisterised builds
Ian Lynagh wrote: On Thu, Mar 16, 2006 at 10:05:44AM +, Simon Marlow wrote: That's right - registerised and unregisterised code are completely incompatible. OK, thanks. Its similar to the situation with profiled and unprofiled code. But in this case we get a warning: "mismatched interface file ways: expected , found p" Perhaps a similar warning could be given for the registerised case? Done. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mixing registerised and unregisterised builds
On Thu, Mar 16, 2006 at 10:05:44AM +, Simon Marlow wrote: > > That's right - registerised and unregisterised code are completely > incompatible. OK, thanks. > Its similar to the situation with profiled and unprofiled code. But in this case we get a warning: "mismatched interface file ways: expected , found p" Perhaps a similar warning could be given for the registerised case? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: ghc releasing memory during compilation
Hello John, Thursday, March 16, 2006, 4:00:34 AM, you wrote: >> i suggest checking of AVAILABLE physical ram, that is perfectly >> possible in windows JM> the problem is that available physical ram is wasted ram. any good os JM> will never let there be any available ram because it will fill it up JM> with disk buffers if nothing else. yes, but nevertheless really good operating systems report the avail ram what includes cache buffers. for not-so-good OSes disk cache can be a good measure ;) JM> the only time actual available ram JM> appears is when a big application quits, but then it quicky fills up due JM> to normal disk activity. determining how much of those buffers/cached JM> info you can push out without adversly affecting system performance or JM> thrashing is not very easy so at best we get a sort of approximation. John, not all algorithms are well determined. what we need is just to get "better behavior" in the most of cases JM> the best solution would be for ghc's garbage collector to periodically JM> call getrusage(2) and look at the number of page faults and swaps it is JM> causing and switch to compaction when it sees a jump in that. I don't JM> know what the equivalent routine on windows would be. not all operating JM> systems fill in all the values of getrusage, BSD is the best, linux is JM> the worst at this. but on linux you can get similar info from JM> /proc/self. (i think it does fill in the values we need in getrusage JM> though, I forget which ones it doesn't have) i agree tha this should be even better. windows have such mechanism. but it will be interesting if all our optimization tricks will work only with superuser privileges :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc releasing memory during compilation
John Meacham wrote: On Mon, Mar 13, 2006 at 04:06:59PM +0300, Bulat Ziganshin wrote: SM> I think what you're suggesting is that the runtime should detect the SM> amount of physical memory on the system and auto-tune itself to switch SM> to compacting collection when its residency reaches that amount. This SM> is certainly something we could do. Bear in mind that GHC is not SM> necessarily the only process running on the machine, though, and what SM> about running multiple GHCs? i suggest checking of AVAILABLE physical ram, that is perfectly possible in windows the problem is that available physical ram is wasted ram. any good os will never let there be any available ram because it will fill it up with disk buffers if nothing else. the only time actual available ram appears is when a big application quits, but then it quicky fills up due to normal disk activity. determining how much of those buffers/cached info you can push out without adversly affecting system performance or thrashing is not very easy so at best we get a sort of approximation. the best solution would be for ghc's garbage collector to periodically call getrusage(2) and look at the number of page faults and swaps it is causing and switch to compaction when it sees a jump in that. I don't know what the equivalent routine on windows would be. not all operating systems fill in all the values of getrusage, BSD is the best, linux is the worst at this. but on linux you can get similar info from /proc/self. (i think it does fill in the values we need in getrusage though, I forget which ones it doesn't have) Nice little project for someone... I've added a task: http://hackage.haskell.org/trac/ghc/ticket/728 Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mixing registerised and unregisterised builds
Ian Lynagh wrote: The attached e-mail seems to be about a problem using a library compiled with an unregisterised ghc with a registerised ghc. The linking step is giving many "undefined reference to `stg_ap_p_ret'"s (with various numbers of 'p's) as well as a few to `GHCziIOBase_zdWIO_entry', and possible others I didn't spot, while compiling haskelldb with a registerised ghc 6.4.1, where haskelldb depends on hsql, which was compiled with an unregisterised ghc 6.4.1. Is this expected behaviour? i.e. should I just make sure I don't change which arches are registerised within a GHC version? If so, would a library compiled with a registerised ghc being used by an unregisterised ghc also cause problems? That's right - registerised and unregisterised code are completely incompatible. Its similar to the situation with profiled and unprofiled code. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
