>
> The other way to do the port is to bootstrap from HC files; i.e.,
> forget that any ghc build exists on your architecture, and start from
> scratch.  The method is discussed briefly at
>
> http://www.haskell.org/ghc/docs/latest/building/sec-booting-from-c.html
>
> but basically involves using pre-built, non-gcc-specific C files that
> don't need mangling to build the first stage GHC compiler.

Well, I may be wrong, but I think booting .hc files doesn't avoid mangling step ...

.hs ->| hsc |-> .hc  -> |cc| -> .s -> |mangling| -> .s' -> |assembler| -> .o -> | linker | -> a.out

am I right ?
 

I tried booting from .hc files in linux, sun, and now irix...

Look at the table:
 
platform  sparc-sunos   sparc-sunos i386-linux  i386-linux mips-sgi-irix mips-sgi-irix
gcc-version 2.7.2.3 2.95.1 2.7.2.3 2.95.1 2.95.1 2.7.2.3
ghc-3.02-booting-hc OK NOK OK NOK OK ¿OK?

We should distinguish conceptually  the next "model":
- compiler properly said (hsc) :  .hs -> .hc  ( writen in Haskell (.hs) !! , so I need to mangle !)
- the run-time suport (-l<something>.a , It's almost written in C, something in Haskell .)
- the mangler (ghc-asm.prl)  .s -> .s' (mangles prelude functions, destroying C -stack model )
- the linker ( -lruntimea, .o -> a.out)
- the driver (ghc.prl) . The master overall guide process...
 

The key point I must concentrate is the gcc-mangler interface...That would explain the previous table.
Booting .hc doesn't avoid mangling...as I understand the process.( I may be wrong )

The older mangler (ghc-3.02) seems to be dessigned closely to the gcc 2.7.2.3 output... ( The ghc-4.08 runs on gcc-2.95.1 )
That's why I'm trying to find which one was used to build and run ghc-2.10-mips-sgi-irix6.tar.gz .

Any other e-mail or reference to consult MIPS-port would be acknowledged...

Sorry if my previous mail was large and a bit dark...

> From
> there, you have a Haskell compiler that can be used to compile the
> real GHC natively, and you can work on the mangler etc as necessary.
> No doubt one of the GHC Team will give more details.
>
> In general, the GHC Team is very happy to help with this kind of
> thing, because they want GHC to be available on as many platforms as
> possible.
>