[Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
lukexipd at gmail.com
Mon Aug 12 07:44:40 CEST 2013
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:
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...
On Sun, Aug 11, 2013 at 3:18 PM, Carter Schonwald <
carter.schonwald at 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 <lukexipd at 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:
>> 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:
>> 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
>> (similarly for where and let blocks)
>> On Sun, Aug 11, 2013 at 1:53 AM, Luke Iannini <lukexipd at 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 <lukexipd at 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)
>> On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini <lukexipd at 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-22.214.171.124
>> -package containers-0.5.0.0 -package directory-126.96.36.199 -package
>> filepath-188.8.131.52 -package process-184.108.40.206 -XHaskell98 -XCPP
>> -XForeignFunctionInterface -no-user-package-db -rtsopts -odir
>> utils/hsc2hs/dist/build -hid
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Glasgow-haskell-users