Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?

Why is llvm 3.0 required here? Could you enlighten me please? On Sunday, August 11, 2013, Luke Iannini wrote:

Thanks! That’s all identical to my procedure except that I’m using 10.9 DP5/Xcode 5 DP5, so I guess that must play some role, though I’m not sure what.

Re: iPod Touch authorization, if you haven’t tried in a few days or so, Apple’s now claiming everything’s back online finally https://developer.apple.com/support/system-status/

Cheers Luke

On Sun, Aug 11, 2013 at 5:37 PM, Stephen Blackheath [to GHC-iPhone] < likeliest.complexions.stephen@blacksapphire.com> wrote:

Luke,

I didn't experience anything like you described. Here's as much detail as I can think of about what I did:

* Mac OS/X 10.8.4

* Xcode 4.6

* ghc-7.6.3 downloaded from http://haskell.org/ghc as the bootstrap compiler

* llvm - 3.0 built from source downloaded off the llvm site:

Low Level Virtual Machine (http://llvm.org/): llvm version 3.0 Optimized build. Built Jan 31 2012 (09:33:35). Host: x86_64-apple-darwin12.4.0 Host CPU: penryn

Registered Targets: alpha - Alpha [experimental] arm - ARM ... and others ...

Before I had a problem with not enough memory but I bought some more. So I got a cross compiler built, but wasn't able to test it, because I can't authorize my iPod Touch for development at the moment (Apple systems are down). So I can't verify that it produces iOS executables that work.

The latest commit in the git log for GHC HEAD was this:

commit e8aa8ccba0c40884765281b21ff8f4**411802dd41 Author: Richard Eisenberg Date: Fri Aug 2 15:47:03 2013 +0100

Implement "roles" into GHC. ...

I patched it as attached here (same patch as in my last email).

The procedure I used was exactly the one described at http://ghc.haskell.org/trac/**ghc/wiki/Building/**CrossCompiling/iOShttp://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS

Thanks for your work on this! That problem you're having is pretty weird!

Steve

On 11/08/13 20:14, Luke Iannini wrote:

And the truly final word for the moment : ) — I built a tool to partially automate the indentation workaround for LLVM 3.0 and it yields the same "co-processor offset out of range"/"unsupported relocation on symbol LCPI65_0" errors LLVM 3.3/3.4 did when it finally gets to integer-simple/GHC/Integer/**Type.hs.

On Sun, Aug 11, 2013 at 3:06 AM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

OK! So just to summarize: Building GHC HEAD with LLVM 3.0 or 3.2 (using GHC 7.6.3 as the bootstrap) on OS X 10.9 DP5/Xcode 5 DP5 exhibits very strange behavior wherein layout-based code along with mixed-tabs-and-spaces code fails to parse correctly, with issues in hundreds of files in the GHC HEAD tree. I don't have a 10.8 machine to check if this is a 10.9 exclusive issue, so I'd love if someone can try using these binaries to build GHC HEAD: http://llvm.org/releases/3.0/**clang+llvm-3.0-x86_64-apple-** darwin11.tar.gzhttp://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz

Building GHC HEAD with LLVM 3.3 or 3.4 works great as a regular compiler with the 10.9 workarounds I outlined in another thread, but fails when compiling as a cross-compiler (./configure --target=arm-apple-darwin10) with these errors: https://gist.github.com/**lukexi/2b129f34fa027172c5eehttps://gist.github.com/lukexi/2b129f34fa027172c5ee

So I'm between a rock and a hard place at the moment.

The only (very tedious and slow) workaround I've found for the 3.0/3.2 bug is to manually expand tabs to spaces, and to transform do x y into do x y (similarly for where and let blocks)

Cheers Luke

On Sun, Aug 11, 2013 at 1:53 AM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

Arg