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

12 Aug 2013

      Stephen,

In case it got lost in my slurry of reports — LLVM 3.0 produces the same
"co-processor offset out of range" "unsupported relocation on symbol"
errors that LLVM 3.4 did (here on 10.9) when it hits
libraries/integer-simple/./GHC/Integer/Type.hs.

On Sun, Aug 11, 2013 at 7:20 PM, Stephen Blackheath [to GHC-iPhone] <
likeliest.complexions.stephen@blacksapphire.com> wrote:
...
Carter,
llvm-3.0 works and produces correctly working code,
llvm-3.1 is completely broken due to a regression in the area of GHC
calling convention in ARM - and this was fixed in 3.2,
llvm >= 3.2 should work, but previously we couldn't build GHC because it's
more 'fussy' about its input and GHC hadn't been changed to work with it.
This may have been fixed since.
So llvm-3.0 is the only version that's absolutely confirmed to be working
at present.
Steve
On 12/08/13 10:19, Carter Schonwald wrote:
...
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/https://developer.apple.com/support/system-status/
Cheers
    Luke
On Sun, Aug 11, 2013 at 5:37 PM, Stephen Blackheath [to GHC-iPhone]
    >
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
<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
<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
<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