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 > >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users