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-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 <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/7ca55b36269703236f1f<https://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/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 <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@**gmail.com<carter.schonw...@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 >>>>>> <lukex...@gmail.com <mailto:lukex...@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.** >>>>>> step...@blacksapphire.com<likeliest.complexions.step...@blacksapphire.com> >>>>>> <mailto:likeliest.complexions.** >>>>>> step...@blacksapphire.com<likeliest.complexions.step...@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 >>>>>> iph...@haskell.org <mailto:iph...@haskell.org >>>>>> > >>>>>> >>>>>> http://www.haskell.org/** >>>>>> mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone> >>>>>> >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>>> iPhone mailing list >>>>>> iph...@haskell.org <mailto:iph...@haskell.org> >>>>>> >>>>>> http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>> >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
