Don Stewart wrote:
Could we start documenting this on the wiki ?
It will be interesting to keep track of what we have tried,
what attempts failed and why.
-- Don
I've added some new sections to the top of the wiki page, above the
original attempts. It's now quite long, since it contains details of the
problems I encountered trying to build an unregisterised 6.9.20080614 as
a first experiment.
It ultimately failed because hc-file bootstrapping to a new platform has
been broken since 6.8. Only platforms with an existing GHC prior to 6.8
have 6.8 or later now, because of this. A bug[1] has been up since
mid-2007 detailing the problem. There's a self-proclaimed "quick hack"
diff[2], posted with the following comment:
> The diff I uploaded contains some comments inline. It's for ghc-6.8.2
> but also applies to the latest stable snapshot (ghc-6.8.2.20080401).
>
> As written earlier, it's possible to create a HC file bundle (with
> some additional created files) and to build a stage1 compiler with
> this. I'm a little bit uncertain how to proceed -- either go ahead
> using libcompat (which is a little bit ugly), or try to rebuild all
> the libraries immediately with that stage1 compiler (but without using
> utils/ghc-pkg, since it's not yet buildable), then build the remaining
> tools.
The bug is milestoned for 6.10.1, and the owner, Ian Lynagh (Igloo),
said on #haskell that 6.10.1 merely meant "soon".
So, assuming some GHC dev doesn't swoop down and fix this, what options
are left to the project in the short term?
An unregisterised build of an old 6.6 should work, that would get us a
working, though aging, GHC. Unfortunately a lot of the porting work to
move from that first unregisterised build to a registerised one (even
without native code-gen) wouldn't be transferable to a later 6.9 or
6.10, since 6.9 has moved from using the Evil Mangler to libffi.
As to running GHC on a real ARM device, several steps beyond the first
unregisterised build would have to be taken, regardless of GHC version:
1. Registerise it. Pre-6.9, this means porting parts of the Evil
Mangler, for which there is a guide. Post-6.9, this is much easier.
2. Native code-gen. Registerised or not, a GHC without native code
generation relies on a working gcc. That means a GHC for ARM without NCG
would only allow compilation of apps in the development environment,
though the binaries should work on the device.
3. Finally, even GHC with native code-gen seems to rely on ld and maybe
a few other binutils, but this is much, much lighter than installing all
of gcc.
So, moving forward I intend to run an unregisterised 6.6 build, just to
prove that it can be done. Where we go from there is up in the air. I'd
be inclined at that point to wait for 6.10 if #1346 really gets fixed.
Fully porting an old version seems like extra work that will hopefully
be obsoleted.
Comments here or on the wiki page are most welcome, I'll be documenting
the quirks and changes for the second attempt with 6.6 there too.
And if someone in the GHC know wants to work #1346, they would be my hero.
Braden Shepherdson
shepheb
[1] http://hackage.haskell.org/trac/ghc/ticket/1346
[2] http://hackage.haskell.org/trac/ghc/attachment/ticket/1346/ghc.diff
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
