status of template haskell + cross compiling plans for 7.8?

Alp Mestanogullari alpmestan at
Fri Jun 21 13:20:59 CEST 2013

I recently came across this:

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> 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**
> 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@** <ghc-devs-bounces at>
>> [mailto:ghc-devs-bounces@** <ghc-devs-bounces at>]
>> *On Behalf Of *Carter Schonwald
>> *Sent:* 13 June 2013 22:44
>> *To:* ghc-devs at
>> *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 at
> ______________________________**_________________
> ghc-devs mailing list
> ghc-devs at

Alp Mestanogullari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list