Kick ass ... going through the setup steps right ... now. On Wed, Feb 27, 2013 at 1:48 PM, Peter Jones wrote:

"Stephen Blackheath [to GHC-iPhone]" writes:

...

Cross-compiling GHC to iOS: http://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS

Great work Stephen!

-- Peter Jones --- Love to Develop 303-219-0226 http://devalot.com

_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone

Thanks Simon - I've added that to a list of loose ends on the Building/CrossCompiling/iOS wiki page. All - I've fixed the issues with http://hackage.haskell.org/trac/ghc/ticket/7722, so everything should now be working. Anyone who wants to try it now should either apply all the patches associated with "Blocked By" of http://hackage.haskell.org/trac/ghc/ticket/7724, or check out http://github.com/ghc-ios/ghc on the 'master-merge-ios' branch. Steve On 01/03/13 04:44, Simon Marlow wrote:

On 27/02/13 21:34, Stephen Blackheath [to GHC-iPhone] wrote:

...

All,

Cross-compiling GHC to iOS: http://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS

Great. The point about dead-code removal is interesting: we have special hacks so that you don't have to disable dead-code removal on OS X, in the native code generator and (I presume) in the LLVM backend. Perhaps this just needs to be adapted to work on iOS too?

On the other hand, the special hack involves adding lots of extra symbols, so perhaps it's better to just disable dead-code removal.

Cheers, Simon

Alex, I can't help much because I'm even more confused than you are about subprojects on the ghc-ios repos. Try this: 1. Clone your http://github.com/ghc-ios/ghc repo locally to give yourself a clean checkout. 2. Go into it and check out the 'master' branch: git checkout master 3. Point the 'origin' remote at the central ghc repo. 4. Now do ./sync-all --no-dph get (This will get the stock standard subprojects, just exactly how things would work for a normal ghc checkout from ghc HQ.) 5. Now back to the branch: git checkout master-merge-ios 6. Now you can point 'origin' back to ghc-ios/master-merge-ios again if you want. 7. Follow the rest of the build instructions. Steve On 01/03/13 16:27, Alex Carter wrote:

On a fresh checkout of ghc-ios:ghc/merge-master-ios, I get /sync-all/ and /perl boot/ errors: / /

/$ sync-all --no-dph get/ ... Unable to checkout 'ecf43c78cc1fdc7ef5f9f44ccf35441a2ad33847' in submodule path 'libraries/Cabal' Unable to checkout '8b271670f79a3b50d7e15ca924878212f042f259' in submodule path 'libraries/vector' ...

and then:

$ perl boot Error: libraries/Cabal/LICENSE doesn't exist. Maybe you haven't done './sync-all get'? at boot line 74, <PACKAGES> line 53.

which I suppose makes sense since the Cabal checkout failed...

- Alex

On Thu, Feb 28, 2013 at 4:49 PM, Stephen Blackheath [to GHC-iPhone] mailto:likeliest.complexions.stephen@blacksapphire.com> wrote:

Thanks Simon - I've added that to a list of loose ends on the Building/CrossCompiling/iOS wiki page.

All - I've fixed the issues with http://hackage.haskell.org/__trac/ghc/ticket/7722 http://hackage.haskell.org/trac/ghc/ticket/7722, so everything should now be working.

Anyone who wants to try it now should either apply all the patches associated with "Blocked By" of http://hackage.haskell.org/__trac/ghc/ticket/7724 http://hackage.haskell.org/trac/ghc/ticket/7724, or check out http://github.com/ghc-ios/ghc on the 'master-merge-ios' branch.

Steve

On 01/03/13 04:44, Simon Marlow wrote:

On 27/02/13 21:34, Stephen Blackheath [to GHC-iPhone] wrote:

All,

Cross-compiling GHC to iOS: http://hackage.haskell.org/__trac/ghc/wiki/Building/__CrossCompiling/iOS http://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS

Great. The point about dead-code removal is interesting: we have special hacks so that you don't have to disable dead-code removal on OS X, in the native code generator and (I presume) in the LLVM backend. Perhaps this just needs to be adapted to work on iOS too?

On the other hand, the special hack involves adding lots of extra symbols, so perhaps it's better to just disable dead-code removal.

Cheers, Simon

_________________________________________________ iPhone mailing list iPhone@haskell.org mailto:iPhone@haskell.org http://www.haskell.org/__mailman/listinfo/iphone http://www.haskell.org/mailman/listinfo/iphone

Something to watch out for, when setting the url to the main ghc repo use the git@github.com:ghc/ghc.git and not the http version. For example: git remote set-url origin git@github.com:ghc/ghc.git On Fri, Mar 1, 2013 at 1:45 AM, Stephen Blackheath [to GHC-iPhone] < likeliest.complexions.stephen@blacksapphire.com> wrote:

I forgot to mention an important thing: You will need the Cabal changes from Luke's pull request at https://github.com/haskell/**cabal/pull/1214https://github.com/haskell/cabal/pull/1214

I suggest you check out the normal Cabal, then add the above as a new remote and pull from it. (I am not sure exactly which URL to use.)

On 01/03/13 22:41, Stephen Blackheath [to GHC-iPhone] wrote:

...

Alex,

I can't help much because I'm even more confused than you are about subprojects on the ghc-ios repos. Try this:

1. Clone your http://github.com/ghc-ios/ghc repo locally to give yourself a clean checkout. 2. Go into it and check out the 'master' branch: git checkout master 3. Point the 'origin' remote at the central ghc repo. 4. Now do ./sync-all --no-dph get (This will get the stock standard subprojects, just exactly how things would work for a normal ghc checkout from ghc HQ.) 5. Now back to the branch: git checkout master-merge-ios 6. Now you can point 'origin' back to ghc-ios/master-merge-ios again if you want. 7. Follow the rest of the build instructions.

Steve

On 01/03/13 16:27, Alex Carter wrote:

...

On a fresh checkout of ghc-ios:ghc/merge-master-ios, I get /sync-all/ and /perl boot/ errors: / /

/$ sync-all --no-dph get/ ... Unable to checkout '**ecf43c78cc1fdc7ef5f9f44ccf3544**1a2ad33847' in submodule path 'libraries/Cabal' Unable to checkout '**8b271670f79a3b50d7e15ca9248782**12f042f259' in submodule path 'libraries/vector' ...

and then:

$ perl boot Error: libraries/Cabal/LICENSE doesn't exist. Maybe you haven't done './sync-all get'? at boot line 74, <PACKAGES> line 53.

which I suppose makes sense since the Cabal checkout failed...

- Alex

On Thu, Feb 28, 2013 at 4:49 PM, Stephen Blackheath [to GHC-iPhone] >> wrote:

Thanks Simon - I've added that to a list of loose ends on the Building/CrossCompiling/iOS wiki page.

All - I've fixed the issues with http://hackage.haskell.org/__**trac/ghc/ticket/7722http://hackage.haskell.org/__trac/ghc/ticket/7722 <http://hackage.haskell.org/**trac/ghc/ticket/7722http://hackage.haskell.org/trac/ghc/ticket/7722>, so everything should now be working.

Anyone who wants to try it now should either apply all the patches associated with "Blocked By" of http://hackage.haskell.org/__**trac/ghc/ticket/7724http://hackage.haskell.org/__trac/ghc/ticket/7724 <http://hackage.haskell.org/**trac/ghc/ticket/7724http://hackage.haskell.org/trac/ghc/ticket/7724>, or check out http://github.com/ghc-ios/ghc on the 'master-merge-ios' branch.

Steve

On 01/03/13 04:44, Simon Marlow wrote:

On 27/02/13 21:34, Stephen Blackheath [to GHC-iPhone] wrote:

All,

Cross-compiling GHC to iOS:

http://hackage.haskell.org/__**trac/ghc/wiki/Building/__** CrossCompiling/iOShttp://hackage.haskell.org/__trac/ghc/wiki/Building/__CrossCompiling/iOS

<http://hackage.haskell.org/**trac/ghc/wiki/Building/** CrossCompiling/iOShttp://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS

...

Great. The point about dead-code removal is interesting: we have special hacks so that you don't have to disable dead-code removal on OS X, in the native code generator and (I presume) in the LLVM backend. Perhaps this just needs to be adapted to work on iOS too?

On the other hand, the special hack involves adding lots of extra symbols, so perhaps it's better to just disable dead-code removal.

Cheers, Simon

______________________________**___________________ iPhone mailing list iPhone@haskell.org mailto:iPhone@haskell.org http://www.haskell.org/__**mailman/listinfo/iphonehttp://www.haskell.org/__mailman/listinfo/iphone <http://www.haskell.org/**mailman/listinfo/iphonehttp://www.haskell.org/mailman/listinfo/iphone

...

______________________________**_________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/**mailman/listinfo/iphonehttp://www.haskell.org/mailman/listinfo/iphone

______________________________**_________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/**mailman/listinfo/iphonehttp://www.haskell.org/mailman/listinfo/iphone

Hi Stephen, I installed 10.9 for another project and thus am in the middle of fixing up my system to be able to build GHC again, but I think I'm close — as soon as I have it going I'll try this. In the meantime someone still on 10.8 should definitely try the patch! Hope you're great! Luke On Tue, Aug 6, 2013 at 6:42 PM, Stephen Blackheath [to GHC-iPhone] < likeliest.complexions.stephen@blacksapphire.com> wrote:

Hi all,

A couple of months ago I got some patches applied to GHC mainline for the ability to cross compile to iOS. I've been doing other things and now I want to test those changes. The trouble is, I am having Apple trouble and I can't get Xcode to work.

If anyone is interested in testing it for me, I'd appreciate it.

The patch attached here needs to be applied to GHC head. Using this, I was able to get the cross compiler to build. The instructions are here:

http://ghc.haskell.org/trac/**ghc/wiki/Building/**CrossCompiling/iOShttp://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS

Steve

_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone

Update: I've got GHC HEAD building on 10.9 again, tonight I'll dive into the iOS patch! Cheers Luke On Wed, Aug 7, 2013 at 9:12 PM, Carter Schonwald

wrote:

if you're on 10.8, just DL the 4.6 CLI tools to get things working again.

If you're on 10.9, you'll need to use recent GHC head + CLANG HEAD, (ok, the most recent XCODE 5 dev preview CLI tools may have all the needed clang patches, but thats still needing its own validation, orthogonal to the IOS related issues )

On Tue, Aug 6, 2013 at 7:06 PM, Luke Iannini wrote:

...

Hi Stephen,

I installed 10.9 for another project and thus am in the middle of fixing up my system to be able to build GHC again, but I think I'm close — as soon as I have it going I'll try this.

In the meantime someone still on 10.8 should definitely try the patch!

Hope you're great! Luke

On Tue, Aug 6, 2013 at 6:42 PM, Stephen Blackheath [to GHC-iPhone] < likeliest.complexions.stephen@blacksapphire.com> wrote:

...

Hi all,

A couple of months ago I got some patches applied to GHC mainline for the ability to cross compile to iOS. I've been doing other things and now I want to test those changes. The trouble is, I am having Apple trouble and I can't get Xcode to work.

If anyone is interested in testing it for me, I'd appreciate it.

The patch attached here needs to be applied to GHC head. Using this, I was able to get the cross compiler to build. The instructions are here:

http://ghc.haskell.org/trac/**ghc/wiki/Building/**CrossCompiling/iOShttp://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS

Steve

_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone

_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone

OK, that got me past that one. Now I'm stuck here during compilation of integer-simple: https://gist.github.com/lukexi/d9f8bfd8bca56d5d0ee9 ("unsupported relocation on symbol"/"co-processor offset out of range") On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini wrote:

OK, I'm underway on this.

First roadbump was:

"inplace/bin/ghc-stage1" -static -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o rts/dist/build/Apply.o

You are using a new version of LLVM that hasn't been tested yet! We will try though...

/usr/local/bin/llc: : error: unable to get target for 'arm-apple-darwin10', see --version and --triple.

which I figured out were because the homebrew LLVM 3.4 only includes host platforms by default (x86/x86-64) Reinstalling it with all-targets enables them all: brew install llvm --with-clang --all-targets --HEAD

Trying again now.

On Thu, Aug 8, 2013 at 5:29 PM, Luke Iannini wrote:

...

Update: I've got GHC HEAD building on 10.9 again, tonight I'll dive into the iOS patch! Cheers Luke

On Wed, Aug 7, 2013 at 9:12 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

if you're on 10.8, just DL the 4.6 CLI tools to get things working again.

If you're on 10.9, you'll need to use recent GHC head + CLANG HEAD, (ok, the most recent XCODE 5 dev preview CLI tools may have all the needed clang patches, but thats still needing its own validation, orthogonal to the IOS related issues )

On Tue, Aug 6, 2013 at 7:06 PM, Luke Iannini wrote:

...

Hi Stephen,

I installed 10.9 for another project and thus am in the middle of fixing up my system to be able to build GHC again, but I think I'm close — as soon as I have it going I'll try this.

In the meantime someone still on 10.8 should definitely try the patch!

Hope you're great! Luke

On Tue, Aug 6, 2013 at 6:42 PM, Stephen Blackheath [to GHC-iPhone] < likeliest.complexions.stephen@blacksapphire.com> wrote:

...

Hi all,

A couple of months ago I got some patches applied to GHC mainline for the ability to cross compile to iOS. I've been doing other things and now I want to test those changes. The trouble is, I am having Apple trouble and I can't get Xcode to work.

If anyone is interested in testing it for me, I'd appreciate it.

The patch attached here needs to be applied to GHC head. Using this, I was able to get the cross compiler to build. The instructions are here:

http://ghc.haskell.org/trac/**ghc/wiki/Building/**CrossCompiling/iOShttp://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS

Steve

_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone

_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone

Luke, Try llvm version 3.0 - that's what I'm using, and it definitely worked before. llvm-3.1 is broken for GHC+ARM. As for llvm >= 3.2, I'm not sure if it's been fixed yet, but it wasn't working last time I tried a couple of months ago. I think this was because llvm is getting fussier about its input and GHC hasn't been "tightened up" yet. It's really easy to build llvm from source. Steve On 09/08/13 20:35, Luke Iannini wrote:

v3 output: https://gist.github.com/lukexi/7ca55b36269703236f1f

On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

OK, that got me past that one.

Now I'm stuck here during compilation of integer-simple: https://gist.github.com/lukexi/d9f8bfd8bca56d5d0ee9

("unsupported relocation on symbol"/"co-processor offset out of range")

On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

OK, I'm underway on this.

First roadbump was:

"inplace/bin/ghc-stage1" -static -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o rts/dist/build/Apply.o

You are using a new version of LLVM that hasn't been tested yet! We will try though... /usr/local/bin/llc: : error: unable to get target for 'arm-apple-darwin10', see --version and --triple.

which I figured out were because the homebrew LLVM 3.4 only includes host platforms by default (x86/x86-64) Reinstalling it with all-targets enables them all: brew install llvm --with-clang --all-targets --HEAD

Trying again now.

On Thu, Aug 8, 2013 at 5:29 PM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

Update: I've got GHC HEAD building on 10.9 again, tonight I'll dive into the iOS patch! Cheers Luke

On Wed, Aug 7, 2013 at 9:12 PM, Carter Schonwald mailto:carter.schonwald@gmail.com> wrote:

if you're on 10.8, just DL the 4.6 CLI tools to get things working again.

If you're on 10.9, you'll need to use recent GHC head + CLANG HEAD, (ok, the most recent XCODE 5 dev preview CLI tools may have all the needed clang patches, but thats still needing its own validation, orthogonal to the IOS related issues )

On Tue, Aug 6, 2013 at 7:06 PM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

Hi Stephen,

I installed 10.9 for another project and thus am in the middle of fixing up my system to be able to build GHC again, but I think I'm close — as soon as I have it going I'll try this.

In the meantime someone still on 10.8 should definitely try the patch!

Hope you're great! Luke

On Tue, Aug 6, 2013 at 6:42 PM, Stephen Blackheath [to GHC-iPhone] mailto:likeliest.complexions.stephen@blacksapphire.com> wrote:

Hi all,

A couple of months ago I got some patches applied to GHC mainline for the ability to cross compile to iOS. I've been doing other things and now I want to test those changes. The trouble is, I am having Apple trouble and I can't get Xcode to work.

If anyone is interested in testing it for me, I'd appreciate it.

The patch attached here needs to be applied to GHC head. Using this, I was able to get the cross compiler to build. The instructions are here:

http://ghc.haskell.org/trac/__ghc/wiki/Building/__CrossCompiling/iOS http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS

Steve

_______________________________________________ iPhone mailing list iPhone@haskell.org mailto:iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone

_______________________________________________ iPhone mailing list iPhone@haskell.org mailto:iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone

The first error on a fresh checkout is "/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -c utils/hsc2hs/./C.hs -o utils/hsc2hs/dist/build/C.o utils/hsc2hs/C.hs:155:3: parse error (possibly incorrect indentation or mismatched brackets) There seem to be two classes of error: one is the layout issue above, but other files can be fixed by simply running 'expand' on them. On Sat, Aug 10, 2013 at 6:42 PM, Luke Iannini wrote:

Hi Stephen/all,

I got LLVM 3.0 installed and started building again but hit a very strange problem now wherein tons of layout-based code (as in http://en.wikibooks.org/wiki/Haskell/Indentation) is suddenly erroring out, e.g. compiler/coreSyn/CoreUnfold.lhs:481:2: parse error (possibly incorrect indentation or mismatched brackets) (some files also seem to be triggered by mixed tabs and spaces)

I can fix the errors one by one by converting the code to use more concrete indentation (like do thing1 thing2 ) but it's all over the tree.

Anyone have any idea what might cause this?

Cheers Luke

On Fri, Aug 9, 2013 at 6:14 AM, Stephen Blackheath [to GHC-iPhone] < likeliest.complexions.stephen@blacksapphire.com> wrote:

...

Luke,

Try llvm version 3.0 - that's what I'm using, and it definitely worked before. llvm-3.1 is broken for GHC+ARM. As for llvm >= 3.2, I'm not sure if it's been fixed yet, but it wasn't working last time I tried a couple of months ago. I think this was because llvm is getting fussier about its input and GHC hasn't been "tightened up" yet.

It's really easy to build llvm from source.

Steve

On 09/08/13 20:35, Luke Iannini wrote:

...

v3 output: https://gist.github.com/**lukexi/7ca55b36269703236f1fhttps://gist.github.com/lukexi/7ca55b36269703236f1f

On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

OK, that got me past that one.

Now I'm stuck here during compilation of integer-simple: https://gist.github.com/**lukexi/d9f8bfd8bca56d5d0ee9https://gist.github.com/lukexi/d9f8bfd8bca56d5d0ee9

("unsupported relocation on symbol"/"co-processor offset out of range")

On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

OK, I'm underway on this.

First roadbump was:

"inplace/bin/ghc-stage1" -static -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-**derivedconstants/header -Iincludes/dist-ghcconstants/**header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o rts/dist/build/Apply.o

You are using a new version of LLVM that hasn't been tested yet! We will try though... /usr/local/bin/llc: : error: unable to get target for 'arm-apple-darwin10', see --version and --triple.

which I figured out were because the homebrew LLVM 3.4 only includes host platforms by default (x86/x86-64) Reinstalling it with all-targets enables them all: brew install llvm --with-clang --all-targets --HEAD

Trying again now.

On Thu, Aug 8, 2013 at 5:29 PM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

Update: I've got GHC HEAD building on 10.9 again, tonight I'll dive into the iOS patch! Cheers Luke

On Wed, Aug 7, 2013 at 9:12 PM, Carter Schonwald >> wrote:

if you're on 10.8, just DL the 4.6 CLI tools to get things working again.

If you're on 10.9, you'll need to use recent GHC head + CLANG HEAD, (ok, the most recent XCODE 5 dev preview CLI tools may have all the needed clang patches, but thats still needing its own validation, orthogonal to the IOS related issues )

On Tue, Aug 6, 2013 at 7:06 PM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

Hi Stephen,

I installed 10.9 for another project and thus am in the middle of fixing up my system to be able to build GHC again, but I think I'm close — as soon as I have it going I'll try this.

In the meantime someone still on 10.8 should definitely try the patch!

Hope you're great! Luke

On Tue, Aug 6, 2013 at 6:42 PM, Stephen Blackheath [to GHC-iPhone]

...

...

wrote:

Hi all,

A couple of months ago I got some patches applied to GHC mainline for the ability to cross compile to iOS. I've been doing other things and now I want to test those changes. The trouble is, I am having Apple trouble and I can't get Xcode to work.

If anyone is interested in testing it for me, I'd appreciate it.

The patch attached here needs to be applied to GHC head. Using this, I was able to get the cross compiler to build. The instructions are here:

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

...

Steve

______________________________** _________________ iPhone mailing list iPhone@haskell.org mailto:iPhone@haskell.org

http://www.haskell.org/**mailman/listinfo/iphonehttp://www.haskell.org/mailman/listinfo/iphone

______________________________**_________________ iPhone mailing list iPhone@haskell.org mailto:iPhone@haskell.org http://www.haskell.org/**mailman/listinfo/iphonehttp://www.haskell.org/mailman/listinfo/iphone

Argh, sorry for the confusion: 3.2 *does* exhibit the issue. 3.3 and 3.4 do not. On Sun, Aug 11, 2013 at 1:39 AM, Luke Iannini wrote:

Further investigation:

I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the problem still occurred.

The problem only occurs with LLVM 3.0.

It is not related to cross-compilation or Stephen's patches: I tested this on multiple fresh clones with --with-gcc=clang.

LLVM 3.2, 3.3 and 3.4 do not exhibit the issue.

If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries here Clang Binaries for MacOS X/x86-64http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz and just drop them in your path.

(Stephen, I'm now trying your patch with LLVM 3.2)

Cheers Luke

On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini wrote:

...

The first error on a fresh checkout is

"/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -c utils/hsc2hs/./C.hs -o utils/hsc2hs/dist/build/C.o

utils/hsc2hs/C.hs:155:3:

parse error (possibly incorrect indentation or mismatched brackets)

There seem to be two classes of error: one is the layout issue above, but other files can be fixed by simply running 'expand' on them.

On Sat, Aug 10, 2013 at 6:42 PM, Luke Iannini wrote:

...

Hi Stephen/all,

I got LLVM 3.0 installed and started building again but hit a very strange problem now wherein tons of layout-based code (as in http://en.wikibooks.org/wiki/Haskell/Indentation) is suddenly erroring out, e.g. compiler/coreSyn/CoreUnfold.lhs:481:2: parse error (possibly incorrect indentation or mismatched brackets) (some files also seem to be triggered by mixed tabs and spaces)

I can fix the errors one by one by converting the code to use more concrete indentation (like do thing1 thing2 ) but it's all over the tree.

Anyone have any idea what might cause this?

Cheers Luke

On Fri, Aug 9, 2013 at 6:14 AM, Stephen Blackheath [to GHC-iPhone] < likeliest.complexions.stephen@blacksapphire.com> wrote:

...

Luke,

Try llvm version 3.0 - that's what I'm using, and it definitely worked before. llvm-3.1 is broken for GHC+ARM. As for llvm >= 3.2, I'm not sure if it's been fixed yet, but it wasn't working last time I tried a couple of months ago. I think this was because llvm is getting fussier about its input and GHC hasn't been "tightened up" yet.

It's really easy to build llvm from source.

Steve

On 09/08/13 20:35, Luke Iannini wrote:

...

v3 output: https://gist.github.com/**lukexi/7ca55b36269703236f1fhttps://gist.github.com/lukexi/7ca55b36269703236f1f

On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

OK, that got me past that one.

Now I'm stuck here during compilation of integer-simple: https://gist.github.com/**lukexi/d9f8bfd8bca56d5d0ee9https://gist.github.com/lukexi/d9f8bfd8bca56d5d0ee9

("unsupported relocation on symbol"/"co-processor offset out of range")

On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

OK, I'm underway on this.

First roadbump was:

"inplace/bin/ghc-stage1" -static -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-**derivedconstants/header -Iincludes/dist-ghcconstants/**header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o rts/dist/build/Apply.o

You are using a new version of LLVM that hasn't been tested yet! We will try though... /usr/local/bin/llc: : error: unable to get target for 'arm-apple-darwin10', see --version and --triple.

which I figured out were because the homebrew LLVM 3.4 only includes host platforms by default (x86/x86-64) Reinstalling it with all-targets enables them all: brew install llvm --with-clang --all-targets --HEAD

Trying again now.

On Thu, Aug 8, 2013 at 5:29 PM, Luke Iannini < lukexipd@gmail.com mailto:lukexipd@gmail.com> wrote:

Update: I've got GHC HEAD building on 10.9 again, tonight I'll dive into the iOS patch! Cheers Luke

On Wed, Aug 7, 2013 at 9:12 PM, Carter Schonwald >> wrote:

if you're on 10.8, just DL the 4.6 CLI tools to get things working again.

If you're on 10.9, you'll need to use recent GHC head + CLANG HEAD, (ok, the most recent XCODE 5 dev preview CLI tools may have all the needed clang patches, but thats still needing its own validation, orthogonal to the IOS related issues )

On Tue, Aug 6, 2013 at 7:06 PM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

Hi Stephen,

I installed 10.9 for another project and thus am in the middle of fixing up my system to be able to build GHC again, but I think I'm close — as soon as I have it going I'll try this.

In the meantime someone still on 10.8 should definitely try the patch!

Hope you're great! Luke

On Tue, Aug 6, 2013 at 6:42 PM, Stephen Blackheath [to GHC-iPhone]

...

>

wrote:

Hi all,

A couple of months ago I got some patches applied to GHC mainline for the ability to cross compile to iOS. I've been doing other things and now I want to test those changes. The trouble is, I am having Apple trouble and I can't get Xcode to work.

If anyone is interested in testing it for me, I'd appreciate it.

The patch attached here needs to be applied to GHC head. Using this, I was able to get the cross compiler to build. The instructions are here:

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

...

Steve

______________________________** _________________ iPhone mailing list iPhone@haskell.org mailto:iPhone@haskell.org

http://www.haskell.org/** mailman/listinfo/iphonehttp://www.haskell.org/mailman/listinfo/iphone

______________________________**_________________ iPhone mailing list iPhone@haskell.org mailto:iPhone@haskell.org http://www.haskell.org/**mailman/listinfo/iphonehttp://www.haskell.org/mailman/listinfo/iphone

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 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

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

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 wrote:

...

Argh, sorry for the confusion: 3.2 *does* exhibit the issue. 3.3 and 3.4 do not.

On Sun, Aug 11, 2013 at 1:39 AM, Luke Iannini wrote:

...

Further investigation:

I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the problem still occurred.

The problem only occurs with LLVM 3.0.

It is not related to cross-compilation or Stephen's patches: I tested this on multiple fresh clones with --with-gcc=clang.

LLVM 3.2, 3.3 and 3.4 do not exhibit the issue.

If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries here Clang Binaries for MacOS X/x86-64http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz and just drop them in your path.

(Stephen, I'm now trying your patch with LLVM 3.2)

Cheers Luke

On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini wrote:

...

The first error on a fresh checkout is

"/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -c utils/hsc2hs/./C.hs -o utils/hsc2hs/dist/build/C.o

utils/hsc2hs/C.hs:155:3:

parse error (possibly incorrect indentation or mismatched brackets)

There seem to be two classes of error: one is the layout issue above, but other files can be fixed by simply running 'expand' on them.

On Sat, Aug 10, 2013 at 6:42 PM, Luke Iannini wrote:

...

Hi Stephen/all,

I got LLVM 3.0 installed and started building again but hit a very strange problem now wherein tons of layout-based code (as in http://en.wikibooks.org/wiki/Haskell/Indentation) is suddenly erroring out, e.g. compiler/coreSyn/CoreUnfold.lhs:481:2: parse error (possibly incorrect indentation or mismatched brackets) (some files also seem to be triggered by mixed tabs and spaces)

I can fix the errors one by one by converting the code to use more concrete indentation (like do thing1 thing2 ) but it's all over the tree.

Anyone have any idea what might cause this?

Cheers Luke

On Fri, Aug 9, 2013 at 6:14 AM, Stephen Blackheath [to GHC-iPhone] < likeliest.complexions.stephen@blacksapphire.com> wrote:

...

Luke,

Try llvm version 3.0 - that's what I'm using, and it definitely worked before. llvm-3.1 is broken for GHC+ARM. As for llvm >= 3.2, I'm not sure if it's been fixed yet, but it wasn't working last time I tried a couple of months ago. I think this was because llvm is getting fussier about its input and GHC hasn't been "tightened up" yet.

It's really easy to build llvm from source.

Steve

On 09/08/13 20:35, Luke Iannini wrote:

> v3 output: https://gist.github.com/**lukexi/7ca55b36269703236f1fhttps://gist.github.com/lukexi/7ca55b36269703236f1f > > > On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini mailto:lukexipd@gmail.com> wrote: > > OK, that got me past that one. > > Now I'm stuck here during compilation of integer-simple: > https://gist.github.com/**lukexi/d9f8bfd8bca56d5d0ee9https://gist.github.com/lukexi/d9f8bfd8bca56d5d0ee9 > > ("unsupported relocation on symbol"/"co-processor offset out of > range") > > > On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini mailto:lukexipd@gmail.com> wrote: > > OK, I'm underway on this. > > First roadbump was: > > > "inplace/bin/ghc-stage1" -static -H32m -O -Iincludes > -Iincludes/dist -Iincludes/dist-**derivedconstants/header > -Iincludes/dist-ghcconstants/**header -Irts -Irts/dist/build > -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts > -irts/dist/build -irts/dist/build/autogen -Irts/dist/build > -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o > rts/dist/build/Apply.o > > > > > You are using a new version of LLVM that hasn't been tested > yet! > We will try though... > /usr/local/bin/llc: : error: unable to get target for > 'arm-apple-darwin10', see --version and --triple. > > > which I figured out were because the homebrew LLVM 3.4 only > includes host platforms by default (x86/x86-64) > Reinstalling it with all-targets enables them all: > brew install llvm --with-clang --all-targets --HEAD > > Trying again now. > > > > > On Thu, Aug 8, 2013 at 5:29 PM, Luke Iannini < > lukexipd@gmail.com > mailto:lukexipd@gmail.com> wrote: > > Update: I've got GHC HEAD building on 10.9 again, tonight > I'll dive into the iOS patch! > Cheers > Luke > > > On Wed, Aug 7, 2013 at 9:12 PM, Carter Schonwald > >> > wrote: > > if you're on 10.8, just DL the 4.6 CLI tools to get > things working again. > > If you're on 10.9, you'll need to use recent GHC > head + > CLANG HEAD, (ok, the most recent XCODE 5 dev preview > CLI > tools may have all the needed clang patches, but > thats > still needing its own validation, orthogonal to the > IOS > related issues ) > > > On Tue, Aug 6, 2013 at 7:06 PM, Luke Iannini > mailto:lukexipd@gmail.com> > wrote: > > Hi Stephen, > > I installed 10.9 for another project and thus am > in > the middle of fixing up my system to be able to > build GHC again, but I think I'm close — as soon > as > I have it going I'll try this. > > In the meantime someone still on 10.8 should > definitely try the patch! > > Hope you're great! > Luke > > > On Tue, Aug 6, 2013 at 6:42 PM, Stephen > Blackheath > [to GHC-iPhone] > stephen@blacksapphire.com > stephen@blacksapphire.com > >> > > wrote: > > Hi all, > > A couple of months ago I got some patches > applied to GHC mainline for the ability to > cross > compile to iOS. I've been doing other things > and > now I want to test those changes. The trouble > is, I am having Apple trouble and I can't get > Xcode to work. > > If anyone is interested in testing it for me, > I'd appreciate it. > > The patch attached here needs to be applied > to > GHC head. Using this, I was able to get the > cross compiler to build. The instructions > are here: > > 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 > > > > > Steve > > ______________________________** > _________________ > iPhone mailing list > iPhone@haskell.org iPhone@haskell.org> > > http://www.haskell.org/** > mailman/listinfo/iphonehttp://www.haskell.org/mailman/listinfo/iphone > > > > ______________________________** > _________________ > iPhone mailing list > iPhone@haskell.org mailto:iPhone@haskell.org > http://www.haskell.org/**mailman/listinfo/iphonehttp://www.haskell.org/mailman/listinfo/iphone > > > > > > >

Hi all, I tried this — building GHC HEAD configured to use the native code gen, and then building the cross compiler using that, and got the same errors as everything else thus far: https://gist.github.com/lukexi/02366ed57171400b961a 10.9 Mavericks is likely coming out in less than a month, along with iOS7 and Xcode5 final, so it's definitely worth sorting this out! Not quite sure what to try next though... Best Luke On Sun, Aug 11, 2013 at 3:18 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

What if you build a copy of head with the native code gen. Then build the cross compiler using head on head?

On Sunday, August 11, 2013, 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 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

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

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 wrote:

Argh, sorry for the confusion: 3.2 *does* exhibit the issue. 3.3 and 3.4 do not.

On Sun, Aug 11, 2013 at 1:39 AM, Luke Iannini wrote:

Further investigation:

I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the problem still occurred.

The problem only occurs with LLVM 3.0.

It is not related to cross-compilation or Stephen's patches: I tested this on multiple fresh clones with --with-gcc=clang.

LLVM 3.2, 3.3 and 3.4 do not exhibit the issue.

If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries here Clang Binaries for MacOS X/x86-64http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz and just drop them in your path.

(Stephen, I'm now trying your patch with LLVM 3.2)

Cheers Luke

On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini wrote:

The first error on a fresh checkout is

"/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hid

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 e8aa8ccba0c40884765281b21ff8f4411802dd41 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/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.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

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:

Argh, sorry for the confusion: 3.2 *does* exhibit the issue. 3.3 and 3.4 do not.

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

Further investigation:

I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the problem still occurred.

The problem only occurs with LLVM 3.0.

It is not related to cross-compilation or Stephen's patches: I tested this on multiple fresh clones with --with-gcc=clang.

LLVM 3.2, 3.3 and 3.4 do not exhibit the issue.

If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries here Clang Binaries for MacOS X/x86-64 http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz and just drop them in your path.

(Stephen, I'm now trying your patch with LLVM 3.2)

Cheers Luke

On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

The first error on a fresh checkout is

"/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -c utils/hsc2hs/./C.hs -o utils/hsc2hs/dist/build/C.o

utils/hsc2hs/C.hs:155:3:

parse error (possibly incorrect indentation or mismatched brackets)

There seem to be two classes of error: one is the layout issue above, but other files can be fixed by simply running 'expand' on them.

On Sat, Aug 10, 2013 at 6:42 PM, Luke Iannini mailto:lukexipd@gmail.com> wrote:

Hi Stephen/all,

I got LLVM 3.0 installed and started building again but hit a very strange problem now wherein tons of layout-based code (as in http://en.wikibooks.org/wiki/Haskell/Indentation) is suddenly erroring out, e.g. compiler/coreSyn/CoreUnfold.lhs:481:2: parse error (possibly incorrect indentation or mismatched brackets) (some files also seem to be triggered by mixed tabs and spaces)

I can fix the errors one by one by converting the code to use more concrete indentation (like do thing1 thing2 ) but it's all over the tree.

Anyone have any idea what might cause this?

Cheers Luke

On Fri, Aug 9, 2013 at 6:14 AM, Stephen Blackheath [to GHC-iPhone] mailto:likeliest.complexions.stephen@blacksapphire.com> wrote:

Luke,

Try llvm version 3.0 - that's what I'm using, and it definitely worked before. llvm-3.1 is broken for GHC+ARM. As for llvm >= 3.2, I'm not sure if it's been fixed yet, but it wasn't working last time I tried a couple of months ago. I think this was because llvm is getting fussier about its input and GHC hasn't been "tightened up" yet.

It's really easy to build llvm from source.

Steve

On 09/08/13 20:35, Luke Iannini wrote:

v3 output: https://gist.github.com/__lukexi/7ca55b36269703236f1f https://gist.github.com/lukexi/7ca55b36269703236f1f

On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini mailto:lukexipd@gmail.com mailto:lukexipd@gmail.com>> wrote:

OK, that got me past that one.

Now I'm stuck here during compilation of integer-simple: https://gist.github.com/__lukexi/d9f8bfd8bca56d5d0ee9 https://gist.github.com/lukexi/d9f8bfd8bca56d5d0ee9

("unsupported relocation on symbol"/"co-processor offset out of range")

On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini mailto:lukexipd@gmail.com mailto:lukexipd@gmail.com>> wrote:

OK, I'm underway on this.

First roadbump was:

"inplace/bin/ghc-stage1" -static -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-__derivedconstants/header

-Iincludes/dist-ghcconstants/__header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o rts/dist/build/Apply.o

You are using a new version of LLVM that hasn't been tested yet! We will try though... /usr/local/bin/llc: : error: unable to get target for 'arm-apple-darwin10', see --version and --triple.

which I figured out were because the homebrew LLVM 3.4 only includes host platforms by default (x86/x86-64) Reinstalling it with all-targets enables them all: brew install llvm --with-clang --all-targets --HEAD

Trying again now.

On Thu, Aug 8, 2013 at 5:29 PM, Luke Iannini mailto:lukexipd@gmail.com mailto:lukexipd@gmail.com>> wrote:

Update: I've got GHC HEAD building on 10.9 again, tonight I'll dive into the iOS patch! Cheers Luke

On Wed, Aug 7, 2013 at 9:12 PM, Carter Schonwald mailto:carter.schonwald@gmail.com

mailto:carter.schonwald@gmail.com>> wrote:

if you're on 10.8, just DL the 4.6 CLI tools to get things working again.

If you're on 10.9, you'll need to use recent GHC head + CLANG HEAD, (ok, the most recent XCODE 5 dev preview CLI tools may have all the needed clang patches, but thats still needing its own validation, orthogonal to the IOS related issues )

On Tue, Aug 6, 2013 at 7:06 PM, Luke Iannini mailto:lukexipd@gmail.com mailto:lukexipd@gmail.com>> wrote:

Hi Stephen,

I installed 10.9 for another project and thus am in the middle of fixing up my system to be able to build GHC again, but I think I'm close — as soon as I have it going I'll try this.

In the meantime someone still on 10.8 should definitely try the patch!

Hope you're great! Luke

On Tue, Aug 6, 2013 at 6:42 PM, Stephen Blackheath [to GHC-iPhone]

mailto:likeliest.complexions.stephen@blacksapphire.com

mailto:likeliest.complexions.stephen@blacksapphire.com>>

wrote:

Hi all,

A couple of months ago I got some patches applied to GHC mainline for the ability to cross compile to iOS. I've been doing other things and now I want to test those changes. The trouble is, I am having Apple trouble and I can't get Xcode to work.

If anyone is interested in testing it for me, I'd appreciate it.

The patch attached here needs to be applied to GHC head. Using this, I was able to get the cross compiler to build. The instructions are here:

http://ghc.haskell.org/trac/____ghc/wiki/Building/____CrossCompiling/iOS http://ghc.haskell.org/trac/__ghc/wiki/Building/__CrossCompiling/iOS

<http://ghc.haskell.org/trac/__ghc/wiki/Building/__CrossCompiling/iOS http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS>

Steve

_________________________________________________ iPhone mailing list iPhone@haskell.org mailto:iPhone@haskell.org mailto:iPhone@haskell.org>

http://www.haskell.org/__mailman/listinfo/iphone http://www.haskell.org/mailman/listinfo/iphone

_________________________________________________ iPhone mailing list iPhone@haskell.org mailto:iPhone@haskell.org mailto:iPhone@haskell.org> http://www.haskell.org/__mailman/listinfo/iphone http://www.haskell.org/mailman/listinfo/iphone

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

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