Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
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 lukex...@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.schonw...@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 lukex...@gmail.comwrote: 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 lukex...@gmail.comwrote: 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 lukex...@gmail.comwrote: Further investigation: I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the problem still occurred. The problem only occurs with LLVM 3.0. It is not related to cross-compilation or Stephen's patches: I tested this on multiple fresh clones with --with-gcc=clang. LLVM 3.2, 3.3 and 3.4 do not exhibit the issue. If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries here Clang Binaries for MacOS X/x86-64http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz and just drop them in your path. (Stephen, I'm now trying your patch with LLVM 3.2) Cheers Luke On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini lukex...@gmail.comwrote: 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
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 lukex...@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 lukex...@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-64http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz and just drop them in your path. (Stephen, I'm now trying your patch with LLVM 3.2) Cheers Luke On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini lukex...@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 lukex...@gmail.comwrote: 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.step...@blacksapphire.com wrote: Luke, Try llvm version 3.0 - that's what I'm using, and it definitely worked before. llvm-3.1 is broken for GHC+ARM. As for llvm = 3.2, I'm not sure if it's been fixed yet, but it wasn't working last time I tried a couple of months ago. I think this was because llvm is getting fussier about its input and GHC hasn't been tightened up yet. It's really easy to build llvm from source. Steve On 09/08/13 20:35, Luke Iannini wrote: v3 output: https://gist.github.com/**lukexi/7ca55b36269703236f1fhttps://gist.github.com/lukexi/7ca55b36269703236f1f On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini lukex...@gmail.com mailto:lukex...@gmail.com wrote: OK, that got me past that one. Now I'm stuck here during compilation of integer-simple: https://gist.github.com/**lukexi/d9f8bfd8bca56d5d0ee9https://gist.github.com/lukexi/d9f8bfd8bca56d5d0ee9 (unsupported relocation on symbol/co-processor offset out of range) On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini lukex...@gmail.com mailto:lukex...@gmail.com wrote: OK, I'm underway on this. First roadbump was:
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
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 lukex...@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 lukex...@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 lukex...@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-64http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz and just drop them in your path. (Stephen, I'm now trying your patch with LLVM 3.2) Cheers Luke On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini lukex...@gmail.comwrote: 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 lukex...@gmail.comwrote: 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.step...@blacksapphire.com wrote: Luke, Try llvm version 3.0 - that's what I'm using, and it definitely worked before. llvm-3.1 is broken for GHC+ARM. As for llvm = 3.2, I'm not sure if it's been fixed yet, but it wasn't working last time I tried a couple of months ago. I think this was because llvm is getting fussier about its input and GHC hasn't been tightened up yet. It's really easy to build llvm from source. Steve On 09/08/13 20:35, Luke Iannini wrote: v3 output: https://gist.github.com/**lukexi/7ca55b36269703236f1fhttps://gist.github.com/lukexi/7ca55b36269703236f1f On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini lukex...@gmail.com mailto:lukex...@gmail.com wrote: OK, that got me past that one. Now I'm stuck here during compilation of
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
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 lukex...@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 lukex...@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 lukex...@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-64http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz and just drop them in your path. (Stephen, I'm now trying your patch with LLVM 3.2) Cheers Luke On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini lukex...@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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
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.schonw...@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 lukex...@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 lukex...@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 lukex...@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-64http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz and just drop them in your path. (Stephen, I'm now trying your patch with LLVM 3.2) Cheers Luke On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini lukex...@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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
Further investigation: I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the problem still occurred. The problem only occurs with LLVM 3.0. It is not related to cross-compilation or Stephen's patches: I tested this on multiple fresh clones with --with-gcc=clang. LLVM 3.2, 3.3 and 3.4 do not exhibit the issue. If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries here Clang Binaries for MacOS X/x86-64http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz and just drop them in your path. (Stephen, I'm now trying your patch with LLVM 3.2) Cheers Luke On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini lukex...@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 lukex...@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.step...@blacksapphire.com wrote: Luke, Try llvm version 3.0 - that's what I'm using, and it definitely worked before. llvm-3.1 is broken for GHC+ARM. As for llvm = 3.2, I'm not sure if it's been fixed yet, but it wasn't working last time I tried a couple of months ago. I think this was because llvm is getting fussier about its input and GHC hasn't been tightened up yet. It's really easy to build llvm from source. Steve On 09/08/13 20:35, Luke Iannini wrote: v3 output: https://gist.github.com/**lukexi/7ca55b36269703236f1fhttps://gist.github.com/lukexi/7ca55b36269703236f1f On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini lukex...@gmail.com mailto:lukex...@gmail.com wrote: OK, that got me past that one. Now I'm stuck here during compilation of integer-simple: https://gist.github.com/**lukexi/d9f8bfd8bca56d5d0ee9https://gist.github.com/lukexi/d9f8bfd8bca56d5d0ee9 (unsupported relocation on symbol/co-processor offset out of range) On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini lukex...@gmail.com mailto:lukex...@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 lukex...@gmail.com mailto:lukex...@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.schonw...@gmail.com
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
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 lukex...@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-64http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz and just drop them in your path. (Stephen, I'm now trying your patch with LLVM 3.2) Cheers Luke On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini lukex...@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 lukex...@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.step...@blacksapphire.com wrote: Luke, Try llvm version 3.0 - that's what I'm using, and it definitely worked before. llvm-3.1 is broken for GHC+ARM. As for llvm = 3.2, I'm not sure if it's been fixed yet, but it wasn't working last time I tried a couple of months ago. I think this was because llvm is getting fussier about its input and GHC hasn't been tightened up yet. It's really easy to build llvm from source. Steve On 09/08/13 20:35, Luke Iannini wrote: v3 output: https://gist.github.com/**lukexi/7ca55b36269703236f1fhttps://gist.github.com/lukexi/7ca55b36269703236f1f On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini lukex...@gmail.com mailto:lukex...@gmail.com wrote: OK, that got me past that one. Now I'm stuck here during compilation of integer-simple: https://gist.github.com/**lukexi/d9f8bfd8bca56d5d0ee9https://gist.github.com/lukexi/d9f8bfd8bca56d5d0ee9 (unsupported relocation on symbol/co-processor offset out of range) On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini lukex...@gmail.com mailto:lukex...@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 lukex...@gmail.com mailto:lukex...@gmail.com wrote: Update: I've got GHC HEAD building on 10.9 again, tonight I'll dive into the iOS patch! Cheers
