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-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 -hid >> >>
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
