Problems building HEAD

[Simon Marlow]

On 09 May 2006 21:19, Reilly Hayes wrote:

> The way I built the registerised .hc files in the original e-mail
> missed several.  However, doing a vanilla make with the following mk/
> build.mk file will generate them:
> 
> ------
> SRC_HC_OPTS     = -H32m -O -fasm -Rghc-timing -keep-hc-files
> GhcStage1HcOpts = -O0 -DDEBUG
> GhcLibHcOpts    = -O
> GhcLibWays      =
> SplitObjs       = NO
> ----
> 
> make hc-file-bundle Project=ghc creates the tar file with the hc
> files. 

Thanks, I've added this to the documentation.

> I've managed to build a stage1 compiler that executes, but I'm not
> sure it works.  I tried a hello world test program as suggested in
> the documentation.  It fails to compile because it can't find the .hi
> files for the prelude.  But, if I understand correctly, I won't
> have .hi files until I've rebuilt the libraries with the stage1
> compiler.  Is this right?

Yes.

> 3) Refinements to your directions
> 
> The following need to be made prior to building RTS
> 
> $MAKE -C utils/unlit boot all
> $MAKE -C utils/mkdirhier boot all
> $MAKE -C driver/mangler
> 
> The RTS build generates endless warnings about .o files having no
> symbols and functions not having previous prototypes.  I googled for
> both and is seems that it is OK, but I would like confirmation.

I can't remember the cause - if you send me a sample of the messages I
might remember.

> utils/genprimopcode is problematic.  The libraries build fails
> without it, but it wants the libraries to be built in order to link.
> SOMEHOW (I think by typing 'make' at the top level) I ended up with a
> viable executable for this.  Unfortunately, I can't recreate it from
> scratch.  Now that I have it, I admit that I've taken to using it to
> salt new builds rather than figure out what is going on.

genprimopcode *should* be compilable because it has .hc files, so it
shouldn't need .hi files from the libraries, in the same way that GHC
itself is compilable.  I imagine there's an ordering problem or somesuch
somewhere, but I'll have to try this myself sometime.

> The following
> 
> readline and ncurses are problematic on the Mac and should be
> replaced with verisons from gnu.  Thanks to whoever posted bug #766,
> I used the following procedure prior to running configure.
> 
> 	o  Download ncurses and readline and install them into
/usr/local/
> lib.  Be sure to build ncurses as shared.
> 	o  set & export  LD_FLAGS=-L/usr/local/lib and CPP_FLAGS=-I/usr/
> local/include
> 	o  make sure these are in your environment when you configure
and do
> your build.

Ok, thanks.

Cheers,
	Simon