status of template haskell + cross compiling plans for 7.8?
alpmestan at gmail.com
Fri Jun 21 13:20:59 CEST 2013
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 <marlowsd at 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/**
> **). 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.
> 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
>> 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!
>> *From:*ghc-devs-bounces@**haskell.org <ghc-devs-bounces at haskell.org>
>> [mailto:ghc-devs-bounces@**haskell.org <ghc-devs-bounces at haskell.org>]
>> *On Behalf Of *Carter Schonwald
>> *Sent:* 13 June 2013 22:44
>> *To:* ghc-devs at 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.
>> ghc-devs mailing list
>> ghc-devs at haskell.org
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs