[LLVMdev] 3.4 branch gcc 4.9 build error

Alp Toker alp at nuanti.com
Tue May 6 08:30:52 PDT 2014


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>


More information about the llvm-dev mailing list