Configuration may fail if -O2, -D_FORTIFY_SOURCE and -Werror are in CFLAGS or CXXFLAGS

[Saur2000]

Describe the bug
In our environment (based on Poky from the Yocto Project), we pass a lot of compiler options via CC, CFLAGS, and CXXFLAGS, which are set in the environment or via meson.cross. These include -O2, -D_FORTIFY_SOURCE, and -Werror. When Meson needs to run the compiler during configuration, e.g., via check_header, this may lead to an unrelated error:

In file included from /usr/include/bits/libc-header-start.h:33,
                 from /usr/include/stdio.h:27,
                 from .../build/meson-private/tmp3fr8c8af/testfile.c:2:
/usr/include/features.h:412:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
  412 | #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
      |    ^~~~~~~
cc1: all warnings being treated as errors

This is due to Meson adding -O0 to the compiler options during configuration tests, which clashes with the use of -D_FORTIFY_SOURCE=2.

To Reproduce

In Meson's top directory:

CFLAGS="-O2 -D_FORTIFY_SOURCE=2 -Werror" ./meson.py setup build test\ cases/common/189\ check\ header/

Expected behavior
Configuration should not fail because -O2, -D_FORTIFY_SOURCE, and -Werror are in CFLAGS or CXXFLAGS.

system parameters

• Is this a cross build or just a plain native build (for the same computer)?

In our environment it is typically a cross build, but as the reproducer above shows, it is easy to reproduce in a plain build.

• what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.)

Linux Arch, Fedora, Gentoo, and OpenSUSE. However, Ubuntu is not affected as they have patched away the warning from glibc's features.h file...

• what meson --version

1.7.0

[eli-schwartz]

These include -O2, -D_FORTIFY_SOURCE, and -Werror.

In general I'm slightly skeptical you should be doing that in the first place. This problem is, at its heart, the fact that -Werror raised an error you didn't expect. Opting in to specific errors tends to be much more reliable.

Meson also offers -D werror=true which runs after configuration.

[Saur2000]

The reason the compiler flags are passed via, e.g., CFLAGS rather than using specific Meson options are because they are set globally and then used by all the individual builds that bitbake starts, regardless of whether they use make, cmake, automake, meson, etc. My problem, and the reason I created this issue, is that it is very easy to affect configuration tests that will silently cause the build to behave differently by adding these flags to CFLAGS.
An alternative to my proposed solution would be to filter out -Werror and similar options from CFLAGS before passing them on to the compiler commands used during configuration. But I am not sure you can do that in a way where you will not break someone's use case... Thus I opted for a solution that should be safe and is directly related to Meson adding the -O0 option to the command line.