On Mon, May 2, 2016 at 2:21 PM, Mark Wielaard <mjw(a)redhat.com> wrote:
On Mon, May 02, 2016 at 01:26:13PM -0700, Filipe Brandenburger
> 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
> Tested: Ran configure with clang-3.5 and built libelf/ tree with
> $ autoreconf -i
> $ ./configure CC=clang-3.5 ...
> $ make -C libelf
I am not against this patch if it makes our compiler feature detection
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).