iOS cross compile instructions now on GHC wiki / progress update
All, Cross-compiling GHC to iOS: http://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS Progress update: I've now submitted all the patches as tickets to GHC. I've hit a regression with http://hackage.haskell.org/trac/ghc/ticket/7722 (this was working in the old 'ios' branch at http://github.com/ghc-ios) but this won't stop trivial programs running. Steve
"Stephen Blackheath [to GHC-iPhone]" <likeliest.complexions.stephen@blacksapphire.com> 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
Kick ass ... going through the setup steps right ... now. On Wed, Feb 27, 2013 at 1:48 PM, Peter Jones <mlists@pmade.com> wrote:
"Stephen Blackheath [to GHC-iPhone]" <likeliest.complexions.stephen@blacksapphire.com> 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
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
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
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] < 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 http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone>
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] <likeliest.complexions.stephen@blacksapphire.com <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>
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/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 '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] <likeliest.complexions.stephen@blacksapphire.com <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>
_______________________________________________ iPhone mailing list iPhone@haskell.org 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/1214<https://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] <likeliest.complexions.**stephen@blacksapphire.com<likeliest.complexions.stephen@blacksapphire.com> <mailto:likeliest.complexions.**stephen@blacksapphire.com<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> <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> <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>
<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> <http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone>
______________________________**_________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone>
______________________________**_________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone>
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 Steve
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:
Steve
_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone
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 <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] < 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:
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
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 <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] < 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:
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, 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> 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 <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] < 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:
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 <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> 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 <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] < 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:
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
v3 output: https://gist.github.com/lukexi/7ca55b36269703236f1f On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini <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 <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> 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 <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] < 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:
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 <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
("unsupported relocation on symbol"/"co-processor offset out of range")
On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini <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 <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 <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 <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] <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>
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
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:
On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini <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 <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 <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 <carter.schonwald@gmail.com <mailto:carter.schonwald@**gmail.com<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 <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] <likeliest.complexions.**stephen@blacksapphire.com<likeliest.complexions.stephen@blacksapphire.com> <mailto:likeliest.complexions.** stephen@blacksapphire.com<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>
http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone>
______________________________**_________________ iPhone mailing list iPhone@haskell.org <mailto:iPhone@haskell.org> http://www.haskell.org/**mailman/listinfo/iphone<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 <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] < 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:
On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini <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 <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 <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 <carter.schonwald@gmail.com <mailto:carter.schonwald@**gmail.com<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 <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] <likeliest.complexions.**stephen@blacksapphire.com<likeliest.complexions.stephen@blacksapphire.com> <mailto:likeliest.complexions.** stephen@blacksapphire.com<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>
http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone>
______________________________**_________________ iPhone mailing list iPhone@haskell.org <mailto:iPhone@haskell.org> http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone>
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 <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 <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] < 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:
On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini <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 <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 < 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 <carter.schonwald@gmail.com <mailto:carter.schonwald@**gmail.com<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 <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] <likeliest.complexions.**stephen@blacksapphire.com<likeliest.complexions.stephen@blacksapphire.com> <mailto:likeliest.complexions.** stephen@blacksapphire.com<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>
http://www.haskell.org/** mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone>
______________________________**_________________ iPhone mailing list iPhone@haskell.org <mailto:iPhone@haskell.org> http://www.haskell.org/**mailman/listinfo/iphone<http://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 <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 <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 <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] < 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:
On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini <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 <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 < 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 <carter.schonwald@gmail.com <mailto:carter.schonwald@**gmail.com<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 <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] <likeliest.complexions.**stephen@blacksapphire.com<likeliest.complexions.stephen@blacksapphire.com> <mailto:likeliest.complexions.** stephen@blacksapphire.com<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>
http://www.haskell.org/** mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone>
______________________________**_________________ iPhone mailing list iPhone@haskell.org <mailto:iPhone@haskell.org> http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone>
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 <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 <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 <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 <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] < 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:
On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini <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 <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 < 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 <carter.schonwald@gmail.com <mailto:carter.schonwald@**gmail.com<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 <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] <likeliest.complexions.** stephen@blacksapphire.com<likeliest.complexions.stephen@blacksapphire.com> <mailto:likeliest.complexions.** stephen@blacksapphire.com<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 >
http://www.haskell.org/** mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone>
______________________________**_________________ iPhone mailing list iPhone@haskell.org <mailto:iPhone@haskell.org> http://www.haskell.org/**mailman/listinfo/iphone<http://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 <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 <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 <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 <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 <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] < 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 <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 <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 < > 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 > <carter.schonwald@gmail.com > <mailto:carter.schonwald@**gmail.com<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 > <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] > <likeliest.complexions.** > stephen@blacksapphire.com<likeliest.complexions.stephen@blacksapphire.com> > <mailto:likeliest.complexions.** > stephen@blacksapphire.com<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> > > http://www.haskell.org/** > mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone> > > > > ______________________________** > _________________ > iPhone mailing list > iPhone@haskell.org <mailto:iPhone@haskell.org> > http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone> > > > > > > >
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 <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 <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 <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 <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 -hid
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 <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 <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 <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 <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 -hid
Hello all! I'm extremely happy to report (thanks to invaluable help from Stephen) that my issues were my own dumb fault : ) — I was using LLVM 3.0's Clang but not its llc or opt. With some other tweaks to Stephen's above patch[1], we now have a perfectly working GHC-iOS on OS X 10.9 Mavericks. Hurray! Cheers Luke [1]Stephen's work: http://ghc.haskell.org/trac/ghc/ticket/8125 http://ghc.haskell.org/trac/ghc/ticket/8126 http://ghc.haskell.org/trac/ghc/ticket/8127 On Mon, Aug 12, 2013 at 1:44 AM, Luke Iannini <lukexipd@gmail.com> wrote:
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 <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 <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 <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 <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 -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 <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 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
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 <lukexipd@gmail.com <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 <lukexipd@gmail.com <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 <lukexipd@gmail.com <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 <lukexipd@gmail.com <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] <likeliest.complexions.stephen@blacksapphire.com <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 <lukexipd@gmail.com <mailto:lukexipd@gmail.com> <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 <lukexipd@gmail.com <mailto:lukexipd@gmail.com> <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 <lukexipd@gmail.com <mailto:lukexipd@gmail.com> <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 <carter.schonwald@gmail.com <mailto:carter.schonwald@gmail.com>
<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 <lukexipd@gmail.com <mailto:lukexipd@gmail.com> <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]
<likeliest.complexions.__stephen@blacksapphire.com <mailto:likeliest.complexions.stephen@blacksapphire.com>
<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 <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 <mailto:iPhone@haskell.org>> http://www.haskell.org/__mailman/listinfo/iphone <http://www.haskell.org/mailman/listinfo/iphone>
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:
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 <lukexipd@gmail.com <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<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 <lukexipd@gmail.com <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 <lukexipd@gmail.com <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<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<likeliest.complexions.stephen@blacksapphire.com> <mailto:likeliest.complexions.** stephen@blacksapphire.com<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>
<https://gist.github.com/** lukexi/7ca55b36269703236f1f<https://gist.github.com/lukexi/7ca55b36269703236f1f>
On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini <lukexipd@gmail.com <mailto: lukexipd@gmail.com> <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>
<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 <lukexipd@gmail.com <mailto:lukexipd@gmail.com> <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 <lukexipd@gmail.com <mailto:lukexipd@gmail.com> <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 <carter.schonwald@gmail.com <mailto:carter.schonwald@**gmail.com<carter.schonwald@gmail.com>
<mailto:carter.schonwald@__gma**il.com<http://gmail.com>
<mailto:carter.schonwald@**gmail.com<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 <lukexipd@gmail.com <mailto:lukexipd@gmail.com> <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]
<likeliest.complexions.__** stephen@blacksapphire.com<likeliest.complexions.__stephen@blacksapphire.com> <mailto:likeliest.complexions.** stephen@blacksapphire.com<likeliest.complexions.stephen@blacksapphire.com>
<mailto:likeliest.complexions.** __stephen@blacksapphire.com<likeliest.complexions.__stephen@blacksapphire.com>
<mailto:likeliest.complexions.** stephen@blacksapphire.com<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>
<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 <mailto:iPhone@haskell.org>>
http://www.haskell.org/__** mailman/listinfo/iphone<http://www.haskell.org/__mailman/listinfo/iphone> <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 <mailto:iPhone@haskell.org>> http://www.haskell.org/__** mailman/listinfo/iphone<http://www.haskell.org/__mailman/listinfo/iphone> <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 <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
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
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] <likeliest.complexions.**stephen@blacksapphire.com<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>
<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>
<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
participants (7)
-
Alex Carter -
Carter Schonwald -
Jonathan Fischoff -
Luke Iannini -
Peter Jones -
Simon Marlow -
Stephen Blackheath [to GHC-iPhone]