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]> 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 <[email protected]> >> [mailto:ghc-devs-bounces@**haskell.org <[email protected]>] >> *On Behalf Of *Carter Schonwald >> *Sent:* 13 June 2013 22:44 >> *To:* [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] >> http://www.haskell.org/**mailman/listinfo/ghc-devs<http://www.haskell.org/mailman/listinfo/ghc-devs> >> >> > > ______________________________**_________________ > ghc-devs mailing list > [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
