Thanks Tom,
That sounds great. Good luck with the release
Alp.
On 6 May 2014 16:21:19 BST, Tom Stellard <tom at stellard.net>
wrote:>On Mon, May 05, 2014 at 11:42:28PM +0100, Alp Toker wrote:
>>
>> On 05/05/2014 20:51, Richard Smith wrote:
>> > On Mon, May 5, 2014 at 10:47 AM, Chandler Carruth
>> > <chandlerc at google.com <mailto:chandlerc at
google.com>> wrote:
>> >
>> > On Mon, May 5, 2014 at 8:11 AM, Alp Toker <alp at
nuanti.com
>> > <mailto:alp at nuanti.com>> wrote:
>> >
>> > I suspect that pulling in clang header fixes r201729,
>r202911
>> > and r207606 to 3.4.1 will resolve libstdc++ / glibc
>> > compatibility issues people have been having with 3.4:
>> >
>> > r201729: Teach Clang to provide ::max_align_t in C11 and
>> > C++11 modes)
>> > r202911: Headers: Provide an ABI compatible max_align_t
>when
>> > _MSC_VER is defined)
>> > r207606: Let stddef.h respect __need_{wchar_t, size_t,
>NULL,
>> > ptrdiff_t, wint_t}.
>> >
>> > The changes look safe to merge but I'd like to hear a
>second
>> > opinion from Chandler or Nico.
>> >
>> >
>> > I believe all of these are very safe, but I respect Tom's
>position
>> > here. As he is managing the release, he gets to say "not
in
>this
>> > one". If you want someone to approve merging these three
>patches
>> > into any release, Richard Smith is the person to ask IMO.
>> >
>> >
>> > The first two are approved for the branch if Tom wants to take
them
>
>> > (and they seem like good fixes to have).
>> >
>> > Tom: if you take r201729, you will need to also take the
>corresponding
>> > libc++ change, r201843.
>> >
>> > r207606 hasn't had much time to bake, and fixes a problem that
is
>not
>> > a regression, so I'd be hesitant to approve it for 3.4.1.
>>
>> Thanks for pointing that out Richard. r201729 + r201843 sounds good.
>>
>> I'm concerned that advice has already appeared online instructing
>users
>> to patch their libstdc++ system headers in order to install clang 3.4
>on
>> Linux. If we don't get the right fix out, distributors will find
>their
>> own way to ship 3.4.1 to the detriment of our users and against our
>own
>> interests.
>>
>
>We can work with distros to make sure they apply the correct fix until
>we can get them into a release.
>
>It's just too late for these to go into 3.4.1. The code has already
>been validated and is ready to be released. However, I have no problem
>with
>doing a 3.4.2 release with these patches. Pushing these off to the
>next
>release will also give us a chance to fully test LLVM 3.4 with gcc 4.9,
>so we will be able to include other fixes as necessary.
>
>-Tom
>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744792 -
>clang-3.4:
>> unusable with libstdc++ from gcc 4.9
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744872 - once
>> gcc-4.9 and g++-4.9 are installed, clang stops properly building
>> existing projects
>> https://bugzilla.redhat.com/show_bug.cgi?id=1092622 - clang-3.4:
>> unusable with libstdc++ from gcc 4.9
>>
>> Alp.
>>
>> --
>> http://www.nuanti.com
>> the browser experts
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140506/aee719b1/attachment.html>