Custom ghcPrimIface for cross-compilation?

Luite Stegeman stegeman at
Fri Mar 16 14:09:57 UTC 2018


Normally when you build a cross compiler, you build the GHC sources
configured for the target platform. Your GHC.Prim would already expect 32
bit, so the hook is not needed. However if you want to use the ghc library
to build a non-standard cross compiler (GHCJS in my case), it may be
useful. I added the `ghcPrimIface` hook for this purpose: GHCJS essentially
targets a 32 bit platform, and it's a standalone program that uses the
existing (already installed) `ghc` library.

But this is really a stop-gap solution. Besides replacing the GHC.Prim
interface, you also need to make sure that the name cache in the GHC
session doesn't contain entries referring to the built-in version, and the
built-in rewrite rules also need to be avoided. And apparently there are
more places: In GHCJS on GHC 8.0 it is possible to get type errors that
shouldn't have been there, caused by differences between the original and
replaced GHC.Prim module.

For GHC 8.2 I made the decision to abandon the use of the ghcPrimIface
hook, instead building GHCJS against a "private" ghc library (under the
cabal package name `ghc-api-ghcjs` ). The `ghc-api-ghcjs` library always
targets 32 bit. Once we have a better way to dynamically change the target
in the `ghc` library, GHCJS can drop the customized library.


On Fri, Mar 16, 2018 at 6:12 AM Shao Cheng <astrohavoc at> wrote:

> Hi all, is it possible for a 64-bit ghc to emit 32-bit code, if I supply a
> custom ghcPrimIface via Hooks and also modify the platform flags in
> DynFlags? The module does not import Prelude and has no dependencies other
> than GHC.Prim. _______________________________________________
> ghc-devs mailing list
> ghc-devs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list