This is the mail archive of the
mailing list for the glibc project.
Re: why Glibc does not build with clang?
- From: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 19 May 2014 12:00:05 +0400
- Subject: Re: why Glibc does not build with clang?
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdw135gBO+cTQx3Ws1GrRgFsi8-j=Y_mZ=ixebpPzB4gXw at mail dot gmail dot com>
Thanks for moving the (interesting!) alloca discussion to a separate subject.
Any comments on the original questions?
On Fri, May 16, 2014 at 3:26 PM, Konstantin Serebryany
> Today if you try to build Glibc with clang the compilation will fail
> on a few dozen files.
> The largest offenders are local functions  and VLAIS .
> There are ~5 other easily fixable things, not worth discussing.
> Would the Glibc team consider patches that remove local functions and VLAIS?
> Is there any reason (technical/political/social/religious?) to keep
> non-standard extensions
> in Glibc, or this is just a lack of hands to do the cleanup?
> (No intention to initiate a holly war, just want to know :)
> Ability to build with clang may bring some new benefits to Glibc developers,
> such as new warnings or some dynamic testing tools not available in GCC.
> In particular I am interested in building Glibc with MemorySanitizer
> to find bugs
> in Glibc itself and to find more bugs in user code.
> Thanks (and excuse me if this is some trivial FAQ),
> "error: function definition is not allowed here"
> locale/weight.h:23 # included into other files.
> sysdeps/x86_64/dl-machine.h:239 #included into other files
> error: fields must have a constant size: 'variable length array in
> extension will never be supported