Hello Everyone, I sent a couple of private messages to Simon and he suggested I post to the list instead to get more eyes on the problem. I have been working for the better part of 3 days on trying to get GHC to build within an Open Embedded environment. Open Embedded is used to set up embedded build environments that are completely isolated from the build platform. The problem I'm encountering is due to the way GHC builds its requiring the build and host platforms to be the same. I want to create a GHC build where the build and host are different so I can guarantee the isolation of the Haskell used to build our programs and libraries on target. I looked extensively through the cross compilation wiki page and even tried specifying paths into configure script to specify the tools from within my toolchain to build with and I am still running into problems. It seems that even if the top level makefile gets configured properly the build environment for the modules created with cabal under libraries do not retain any of that configuration information. The reason this is important is that I'm working on OpenXT which is a recently Open Sources version of a product Citrix use to have called Xen Client XT. The idea of OpenXT is that we use Xen to decompose what is traditionally a monolithic system into several VMs which serve specific purposes. For example we have the user interface for the platform which manages things like sound levels and bringing up and shutting down VMs into its own domain called the UI domain. We also separate out networking into its own domain as well where the network card is mapped exclusively into that domain and it manages creating and running virtual network adapters for other VMs on the platform. 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. Dave
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
participants (2)
-
dpquigl -
Reid Barton