ARM64 Task Force
Howdy all, Would anyone like to team up on getting ARM64 support into GHC? Cheers Luke ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC iOS 7.8.1 RC1 for Device Simulator
Hi folks, RC builds of GHC iOS are now ready for devices and the iOS simulator. https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-simulator/ghc-7.8.20140130-i386-apple-ios.tar.bz2 You'll find complete instructions on their usage here, including compiling cabal packages: https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md Please let me know how it goes! Cheers Luke ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC iOS ARMv7/ARMv7s fat support completed
Hi folks, Happy to report that I've finished an approach to armv7/armv7s fat compilation, just in time for 7.8's imminent release. You'll find the necessary scripts here: https://github.com/ghc-ios/ghc-ios-scripts and the latest instructions for building GHC for iOS usage here: https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS I've also added support for a perf-cross BuildFlavour, which will give a higher-performance and profiling-ready build that matches what we'll be putting together as the official 7.8 GHC iOS binaries: https://ghc.haskell.org/trac/ghc/ticket/8700 Cheers Luke ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] Xcode 5 support for GHC iOS
Hi all, Just wanted to let you know I've finished updating GHC iOS to support Xcode 5. The new scripts are at https://github.com/ghc-ios/ghc-ios-scripts/tree/xcode5 and you'll find updated instructions at http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS . Please let me know if you have any trouble! Cheers Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announcing GHC iOS
Hi all! (in case you don't read /r/haskell : )) Stephen Blackheath and I are extremely happy to report that as of today, GHC can natively build binaries for iOS devices and the iOS Simulator. You'll find everything you need here: http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS The short of it is you can use ghc-ios myFiles.hs to get a universal ARMv7/ARMv7s/i386 static library to drop straight into an Xcode project. Stephen's already working on some wonderful FRP-powered games, I'm working on a project called SpaceTime that I'll announce shortly, and you may now all begin creating insanely great iOS software using the finest language in the world : ). Stephen deserves the lion's share of the credit for this project — it's been over 3 years in the making! Many thanks to Maxwell Swadling for generalizing static library builds into a -staticlib flag for GHC, Carter Schonwald for compilation guidance, and the venerable Austin Seipp for reviewing and merging our patches. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing GHC iOS
Stephen provided some more credits — thanks so much to all! Three connected projects concerning cross-compilation: *Registerised ARM support, added using David Terei's LLVM compiler back end with Stephen Blackheath doing an initial ARMv5 version and LLVM patch and Karel Gardas working on floating point support, ARMv7 compatibility and LLVM headaches. Ben Gamari did work on the runtime linker for ARM. *General cross-compiling, with much work by Stephen Blackheath and Gabor Greif (though many others have worked on this). *A cross-compiler for Apple iOS. iOS-specific parts were mostly Stephen Blackheath with Luke Iannini on the Cabal patch, testing and supporting infrastructure, also with assistance and testing by Miëtek Bak and Jonathan Fischoff, and thanks to many others for testing; The iOS cross compiler was started back in 2009 by Stephen Blackheath with funding from Ryan Trinkle of iPwn Studios. Thanks to Ian Lynagh for making it easy for us with integration, makefile refactoring and patience, and to David Terei for LLVM assistance. On Thu, Aug 29, 2013 at 1:43 PM, Luke Iannini lukex...@gmail.com wrote: Hi all! (in case you don't read /r/haskell : )) Stephen Blackheath and I are extremely happy to report that as of today, GHC can natively build binaries for iOS devices and the iOS Simulator. You'll find everything you need here: http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS The short of it is you can use ghc-ios myFiles.hs to get a universal ARMv7/ARMv7s/i386 static library to drop straight into an Xcode project. Stephen's already working on some wonderful FRP-powered games, I'm working on a project called SpaceTime that I'll announce shortly, and you may now all begin creating insanely great iOS software using the finest language in the world : ). Stephen deserves the lion's share of the credit for this project — it's been over 3 years in the making! Many thanks to Maxwell Swadling for generalizing static library builds into a -staticlib flag for GHC, Carter Schonwald for compilation guidance, and the venerable Austin Seipp for reviewing and merging our patches. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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: inplace/bin/ghc
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
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 mailto:carter.schonwald
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
Re: [Haskell-cafe] GHC for mobile devices?
Hi All, https://github.com/ghc-ios/ghc/wiki explains how to get Stephen Blackheath's GHC fork for iOS running — it's a bumpy road (cleanups are underway) but I've got Cloud Haskell, ObjectiveHaskell, LevelDB and my own libraries running wonderfully on my iPad. I just updated the wiki with a few tweaks for Mountain Lion and Xcode 4.5.2. Cheers Luke On Mon, Nov 12, 2012 at 1:41 AM, Ivan Perez ivanperezdoming...@gmail.com wrote: I found [1] a few months ago. It outputs Java bytecode, so it should work on android. Given that Android development in java is very well supported in eclipse, you might want to use haskell/frege only for the internals of your program and keep coding your interface in Java. [1] http://code.google.com/p/frege/ On 10 November 2012 01:51, Andrew Pennebaker andrew.penneba...@gmail.com wrote: I'd love to use Haskell directly for making mobiles apps. How can we make this happen, porting GHC to Android, iOS, and Windows Phone? -- Cheers, Andrew Pennebaker www.yellosoft.us ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
