Use of GHC in Open Embedded Environments

[Reid Barton]

Hi Dave,

Have you seen https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling?

In GHC's build system the build, host and target are relative to the stage1
compiler only, which will be a cross-compiler when host /= target.

Since the GHC ABI and interface file format can change arbitrarily between
different versions of GHC, programs built by the stage1 compiler must be
linked against libraries that were also built by the stage1 compiler (since
by definition the stage1 compiler is the first build of the new GHC
version). In order to build those libraries, the build system needs to be
able to run the stage1 compiler, which runs on host. So, either build must
equal host (which is what the GHC build system expects), or the build
system would have to somehow communicate with a second system of platform
host to build the libraries there.

However, if you also build the stage2 compiler, since it was built by the
stage1 compiler, which targets target, the stage2 compiler will be a native
compiler that runs on and targets target, and it will be capable of dynamic
code loading (ghci and Template Haskell). This is the most common thing to
want when building a compiler that runs on a platform other than the build
platform, though other configurations are (at least theoretically) possible.

We use haskell in two different ways in this system. We personally want
> to use OpenXT as a research platform and we have special purpose mini
> domains for doing things like measurement and attestation and we have
> components of these written in Haskell to do formal verification of the
> domains. What OpenXT is using Haskell for directly is as part of its
> management engine for the platform. We have a haskell and ocaml(just for
> glue) based versions of metadata storage and platform management APIs.
> Now when we build the platform we want to remove the dependency on the
> host platform GHC version. We try to do this by building what would
> essentially be a stage 1 compiler which will then be used to build the
> runtime and tools used in the final platform VMs. The issue is that the
> GHC build does not recognize the use case of host and build machines
> being different. They expect host and build to be the same and target to
> be different. Because of this even if we specify each component
> individually on the configure line for the base GHC build when the build
> gets to the point of building the libraries it seems to have this
> information completely vanish. I think this is because it is using cabal
> to build the libraries and cabal isn't taking into account that GHC is
> built for a second platform and we want to build those libraries for
> that same platform.
>

I have to say I don't follow what you are trying to do here. If your
question isn't already answered by now, could you be more specific, e.g. "a
stage-n compiler that is built on X, runs on Y and targets Z"? Even if X, Y
and Z are just opaque strings it would be helpful.

Since you mention removing the dependency on the host GHC version, maybe
you want to do an extra bootstrap stage, where instead of building (maybe
cross-compiling) the eventually desired version V with bootstrap compiler
B, you first build a native V compiler, then use that to bootstrap the
cross-compile. However, in theory the stage2 compiler should not depend at
all on the choice of bootstrap compiler.

Regards,
Reid Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150406/950a278d/attachment.html>