PSA: GHC can now be built with Clang

[Gabor Greif]

Please make sure that all bugs are reported back to the Clang devs.
They are usually very fast in fixing them.

I assume that the ${CPP} is in traditional mode?

Cheers,

    Gabor


On 6/19/13, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> Awesome!
>
> I'm actually hitting another CPP bug right now in building ghc head with
> clang head, also I'll reach out to an apple dude i know to find out if we
> can get any help from them on this or the related TLS issue.
>
>
> On Wed, Jun 19, 2013 at 12:44 AM, Austin Seipp <aseipp at pobox.com> wrote:
>
>> Hi all,
>>
>> As of commit 5dc74f it should now be possible to build a working
>> stage1 and stage2 compiler with (an extremely recent) Clang. With some
>> caveats.
>>
>> You can just do:
>>
>> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang
>> $ make
>>
>> I have done this work on Linux. I don't expect much difficulty on Mac
>> OS X, but it needs testing. Ditto with Windows, although Clang/mingw
>> is considered experimental.
>>
>> The current caveats are:
>>
>>  * The testsuite will probably fail everywhere, because of some
>> warnings that happen during the linking phase when you invoke the
>> built compiler. So the testsuite runner will probably be unhappy.
>> Clang is very noisy about unused options, unlike GCC. That needs to be
>> fixed somewhere in DriverPipeline I'd guess, but with some
>> refactoring.
>>  * Some of the stage2 libraries don't build due to a Clang bug. These
>> are vector/primitive/dph so far.
>>  * There is no buildbot or anything to cover it.
>>
>> You will need a very recent Clang. Due to this bug (preventing
>> primitive etc from building,) you'll preferably want to use an SVN
>> checkout from about 6 hours ago at latest:
>>
>> http://llvm.org/bugs/show_bug.cgi?id=16363
>>
>> Hilariously, this bug was tripped on primitive's Data.Primitive.Types
>> module due to some CPP weirdness. But even with a proper bugfix and no
>> segfault, it still fails to correctly parse this same module with the
>> same CPP declarations. I'm fairly certain this is another bug in
>> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately
>> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But
>> it will *probably* work if we just get rid of the CPP tomfoolery in
>> primitive. I'll be testing it in the next few days to see if we can
>> get 3.3 supported. (I'm sort of kicking myself in the head for not
>> doing this a week or two ago...)
>>
>> Anyway, there are some rough edges but it should be in shape for 7.8 I
>> hope. It should be especially welcome for Mac users. (I'm also hoping
>> modern Macs could even go all-clang-all-the-time if my fix for #7602
>> can go in soon...)
>>
>> PS. If you use ASSERT, I just fixed a lot of instances of using that
>> macro, involving whitespace between the name and arguments (commit
>> d8ee2b.) Clang does not forgive you for this. Should I note this
>> anywhere for the future in the wiki or something?
>>
>> --
>> Regards,
>> Austin - PGP: 4096R/0x91384671
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>