
Template Haskell support in ghc-android is not complete. ghc-android merely builds a stage1 cross-compiler with template Haskell enabled. It still needs work done to allow the stage1 cross-compiler to load host architecture libraries from the stage0 host compiler’s library path. I’m hoping that it shouldn’t be too difficult, but I haven’t had a chance to work on it yet. This technique of course requires that the user install the required libraries for both compilers, but I don’t see that as a problem. A nice side effect of doing it this way is that you can have multiple cross-compilers relying on the same stage0 host compiler. This is great for multiple arch targets like Android. On 2013-06-21 13:20, Alp Mestanogullari wrote:
I recently came across this: https://github.com/neurocyte/ghc-android
The "build" script there together with the patches in the 'patch' directory seem to take care of the issues mentioned on this thread. Of course, that's quite a hacky way to make this work, but maybe Luite's work and this one could inspire a good long-term solution.
On Wed, Jun 19, 2013 at 11:44 AM, Simon Marlow
mailto:marlowsd@gmail.com> wrote: The issue that we hit sooner than this is that when we build a cross-compiler, we build all the libs for the target platform and not the host platform (see http://hackage.haskell.org/__trac/ghc/wiki/CrossCompilation http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation__). So to make TH work, we have to change the way we build cross compilers, and make the build system able to build and install two sets of libs. This is probably a big job.
I think it might be possible to avoid needing a multi-target GHC, as long as you have two identical GHCs, one that produces code for the host platform (host-GHC) and one for the target platform (cross-GHC). You compile all the code once with host-GHC, and then again with the cross-GHC, the second time using the .o files produced by host-GHC to run the TH code.
Cheers, Simon
On 17/06/13 14:52, Simon Peyton-Jones wrote:
I have not been following the details of this debate, but there is a good reason why TH doesn’t work on a cross compiler. Specifically, suppose module M imports module X, which defines a function mkD that M calls in a splice, thus $(mkD “wobble”).
Currently, we compile X to X.o, and when compiling M we dynamically link X.o (and all the other libraries it relies on) into GHC so that we can call foo. Obviously X.o has to be runnable on the machine doing the compiling, so if X.o is for some other architecture that’s not going to work.
There is no reason in principle why one could not compile X into X.bytecode (along with all its dependencies), where X.bytecode is architecture independent. Then X.bytecode could be interpreted on any platform. But GHC has no mechanism for doing this at all. I’ve always take the view that if you want X.bytecode, you may as well load X.hs and translate it into bytecode. A bit slower, to be sure, but maybe fast enough. But don’t forget those libraries.
Anyway that’s the state of play. Have fun!
Simon
*From:*ghc-devs-bounces@__haskell.org mailto:ghc-devs-bounces@haskell.org [mailto:ghc-devs-bounces@__haskell.org mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Carter Schonwald *Sent:* 13 June 2013 22:44 *To:* ghc-devs@haskell.org mailto:ghc-devs@haskell.org *Subject:* status of template haskell + cross compiling plans for 7.8?
Hey All,
Whats the story planned for template haskell + cross compiler support come ghc 7.8?
I understand theres a lot of Template Haskell design underway, some of which will help support tools like Manuel's Inline-Objective-C work. Does this mean that factored out within this reorganization is a better story for cross compilation?
Especially since one kill "app" for the Inline-Objective-C template haskell work would be writing IOS applications. Though I guess that also touches on the need to sort out supporting "FAT" ARM binaries too, right?
This intersects with a few different large subsets of tickets, so i'm not sure if any single ticket is the right fora for this question.
thanks!
-Carter
_________________________________________________ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs
_________________________________________________ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs
-- Alp Mestanogullari
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- CJ van den Berg mailto:cj@vdbonline.com xmpp:neurocyte@gmail.com