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 <[email protected] > <mailto:[email protected]>> 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:[email protected]> > [mailto:ghc-devs-bounces@__haskell.org > <mailto:[email protected]>] *On Behalf Of *Carter > Schonwald > *Sent:* 13 June 2013 22:44 > *To:* [email protected] <mailto:[email protected]> > *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 > [email protected] <mailto:[email protected]> > http://www.haskell.org/__mailman/listinfo/ghc-devs > <http://www.haskell.org/mailman/listinfo/ghc-devs> > > > > _________________________________________________ > ghc-devs mailing list > [email protected] <mailto:[email protected]> > http://www.haskell.org/__mailman/listinfo/ghc-devs > <http://www.haskell.org/mailman/listinfo/ghc-devs> > > > > > -- > Alp Mestanogullari > > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs > -- CJ van den Berg mailto:[email protected] xmpp:[email protected] _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
