Hi, 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. Luite On Fri, Mar 16, 2018 at 6:12 AM Shao Cheng <astrohavoc@gmail.com> 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs