[Haskell-iPhone] Can anyone help me test GHC-iOS compiler?

Luke Iannini lukexipd at gmail.com
Tue Aug 13 10:03:55 CEST 2013


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 <lukexipd at 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.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:
>>> 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 <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)
>>>
>>> Cheers
>>> Luke
>>>
>>>
>>> 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-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
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130813/9eccf964/attachment.htm>


More information about the ghc-devs mailing list