Re: [Mingw-w64-public] rubenvb Clang 3.1 experimental build (32-bit)

[Joshua B. <rap...@ra...>]

On Tue, May 8, 2012 at 6:03 PM, Joshua Boyce
<rap...@ra...>wrote:

> On Tue, May 1, 2012 at 4:52 AM, Ruben Van Boxem <van...@gm...>wrote:
>
>> Hi everyone,
>>
>> You might be starting to get the feeling I'm spamming with releases, I
>> like to think of it as catching up.
>>
>> What I bring now is a small gem. It is a package that includes a Clang
>> build coupled with a GCC with libstdc++ that actually work well together.
>> C++ exception handling works as far as I can tell, which is a welcome
>> improvement over all my previous attempts.
>>
>> Note that the GCC in this package uses a different underlying mechanism
>> for C++ exceptions, namely dwarf2, which is incompatible with the usual
>> MinGW-w64 sjlj stuff. So don't mix the two. Otherwise everything should be
>> nicely functional.
>>
>> In case of problems, let me know.
>>
>> Enjoy!
>>
>> Ruben
>>
>> PS: Download link:
>>
>> https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/experimental/i686-w64-mingw32-clang-3.1_rubenvb.7z/download/
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Mingw-w64-public mailing list
>> Min...@li...
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>>
> HUGE thanks for continuing to provide these builds Ruben. (And also the
> GCC builds which I make heavy use of)
>
> I was actually going to report a problem to you, but it seems that you
> yourself have beaten me to it:
> http://llvm.org/bugs/show_bug.cgi?id=12707
>
> This is the only major issue I've come up against so far. I tried
> compiling Boost using this Clang build (under -std=c++11), and the only two
> errors (other than the persistent Boost.Python configuration error which
> also exists under GCC with -std=c++11) were the error above, and another
> one that seemed to be caused by the Boost code itself (something to do with
> the allocators in Boost.Unordered.).
>
> It's exciting that Clang is finally nearing a point where it can be
> considered truly usable on Windows.
>
> Thanks again.
>
>
Just a heads up, <atomic> seems to be broken too.

Thanks.