<div dir="ltr">Hi Dave,<br><br><div class="gmail_extra">Have you seen <a href="https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling">https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling</a>?<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">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.<br><br>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.<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We use haskell in two different ways in this system. We personally want<br>
to use OpenXT as a research platform and we have special purpose mini<br>
domains for doing things like measurement and attestation and we have<br>
components of these written in Haskell to do formal verification of the<br>
domains. What OpenXT is using Haskell for directly is as part of its<br>
management engine for the platform. We have a haskell and ocaml(just for<br>
glue) based versions of metadata storage and platform management APIs.<br>
Now when we build the platform we want to remove the dependency on the<br>
host platform GHC version. We try to do this by building what would<br>
essentially be a stage 1 compiler which will then be used to build the<br>
runtime and tools used in the final platform VMs. The issue is that the<br>
GHC build does not recognize the use case of host and build machines<br>
being different. They expect host and build to be the same and target to<br>
be different. Because of this even if we specify each component<br>
individually on the configure line for the base GHC build when the build<br>
gets to the point of building the libraries it seems to have this<br>
information completely vanish. I think this is because it is using cabal<br>
to build the libraries and cabal isn't taking into account that GHC is<br>
built for a second platform and we want to build those libraries for<br>
that same platform.<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br></div><div>Regards,<br></div><div>Reid Barton<br></div></div></div></div>