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/

    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 <eir@cis.upenn.edu>
        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/iOS

        <http://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
            <lukexipd@gmail.com
            <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.gz

            <http://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/2b129f34fa027172c5ee

            <https://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
            <lukexipd@gmail.com
                 <mailto:lukexipd@gmail.com>> wrote:

                     Arg