This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: [PATCH] config: Pass the compiler -Werror during warning detection
- From: Filipe Brandenburger <filbranden at google dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Mon, 02 May 2016 14:46:14 -0700
- Subject: Re: [PATCH] config: Pass the compiler -Werror during warning detection
Hi Mark,
On Mon, May 2, 2016 at 2:21 PM, Mark Wielaard <mjw@redhat.com> wrote:
> On Mon, May 02, 2016 at 01:26:13PM -0700, Filipe Brandenburger wrote:
>> Otherwise the compilation prints a warning but exits with 0 return code.
>> However, later during the compilation, when -Werror is enforced to about
>> every file, the unsupported options start breaking the builds.
>
> Odd. Normally bad command line options should always cause a non-zero
> exit code. Do you know if that was done deliberate or if it was fixed
> in a later version of the compiler?
This seems to be deliberately done in clang (perhaps for easier
compatibility with other compilers?)... An invalid option produces a
-Wunknown-warning-option warning which is by default enabled as a
warning and not an error... -Werror=unknown-warning-option turns those
into errors and -Werror itself will turn that one on as part of all
the others...
>> Tested: Ran configure with clang-3.5 and built libelf/ tree with it.
>>
>> $ autoreconf -i
>> $ ./configure CC=clang-3.5 ...
>> $ make -C libelf
>
> I am not against this patch if it makes our compiler feature detection
> better.
I'd say it makes configure closer to build, considering during build
time the Makefile is already adding -Werror to most targets.
Furthermore, the check for -Wlogical-op was already using -Werror as
well, so I don't see why not have the three others be consistent with
it (granted, the -Wlogical-op one actually uses non-trivial code,
while the others just compile a trivial file.)
> But clang really isn't supported.
Yes this is understood :-)
> There have been many patches to try to make elfutils build with it.
Yes we're aware. What we need right now is only libelf/ and that one
seems to build fine with clang only.
> But it seems there are just too many missing features.
I'm not sure I'd call those "features" :-) But I digress...
> In fact configure should check all basic language
> constructs we are using ("gcc with GNU99 support"), so people don't
> accidentially try building with a broken compiler. Does clang now
> implement all gnu99 extensions or is our feature check broken?
No it does not implement them and for instance it will never implement
nested functions. But, as I mentioned, libelf/ tree is sane enough to
build with it.
Right now I have to "trick" configure into skipping that test, with:
$ ./configure CC=clang-3.5 ac_cv_c99=yes
And then the build works, at least of libelf/ subdir.
I hope you agree with my arguments on consistency (-Werror at
configure vs. build time), but if you feel strongly against this patch
we do have some possible workarounds (such as passing -Werror in
CFLAGS of ./configure).
Thank you!
Filipe