#11470: Support changing cross compiler target at runtime -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11378 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * related: => #11378 @@ -45,0 +45,4 @@ + + Related tickets: #11378 (an alternate way to implement this without + implementing multitarget support. If this ticket is solved, that ticket is + moot.) New description: Relevant mailing list thread: https://mail.haskell.org/pipermail/ghc- devs/2016-January/011064.html At the moment, GHC's cross-compiling support requires you to build a cross-compiler for every target platform from scratch. (https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation) There are two reasons for this: 1. GHC uses a configure script to interrogate the GCC toolchain about the vagaries of cross-compilation, some parameters of which get baked into various build system scripts and header files and such. Some of this information wends its way into the final built GHC executable. 2. GHC needs to build the boot libraries, using the stage 1 compiler, targeting the cross compiler. It would be very useful to move this configuration from configure time to run time, so that a user can use GHC as a cross-compiler without having to recompile GHC. That is, we would like to (1) ensure that any information from the configure script can alternately be supplemented at runtime, (2) that users can cross-compile the boot libraries on-demand (since GHC won't ship with the ARM versions of the boot libraries), and (3) rearchitect GHC internally so that it handles knows to keep separate the interface files/package database for various cross compilation targets. Such a change will make cross-compiling more convenient (the iOS cross- compiler currently requires GHC to be built twice, once for ARM and once for the simulator!) and will also pave the way for supporting Template Haskell and compiler plugins in the cross-compiler, since a GHC that knows how to deal with both the target and host platforms can simply ensure that it only loads code built for the host platform (a user can then, if necessary, build code twice, once for the host for Template Haskell, and once for the target). Unclear points of design: * How should GHC get the information about the GCC cross-compiler toolchain (which currently is gotten by `configure`?) Preferably, not by running a `configure` script every time you invoke it. What is this information anyway? * How should GHC rebuild the boot libraries? Maybe `cabal-install` can simply handle this for you. Note: please update the top of this ticket as the design becomes clearer. Related tickets: #11378 (an alternate way to implement this without implementing multitarget support. If this ticket is solved, that ticket is moot.) -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11470#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler