cmake and make run feature tests with different flags

[lrstewart]

Problem:

It looks like make is running the feature tests with the same flags it uses for real compilation, while cmake isn't. That makes the cmake feature tests much more lenient, and leads to some feature tests only failing in make.

For example, cmake runs:

/nix/store/a12yx0i0xh7i39bahq13jhmfplmn69ar-gcc-wrapper-11.3.0/bin/gcc   -c -Werror-implicit-function-declaration -Wno-unused-variable -o CMakeFiles/cmTC_f9a67.dir/S2N_LINUX_SENDFILE.c.o -c /home/ubuntu/s2n-tls/tests/features/S2N_LINUX_SENDFILE.c

While make runs:

cc -std=c99 -Wcast-qual -pedantic -Wall -Werror -Wimplicit -Wunused -Wcomment -Wchar-subscripts -Wuninitialized -Wshadow  -Wcast-align -Wwrite-strings -fPIC -Wno-missing-braces -D_POSIX_C_SOURCE=200809L -O2 -I/home/ubuntu/s2n-tls/libcrypto-root/include/ -I/home/ubuntu/s2n-tls/api/ -I/home/ubuntu/s2n-tls -Wno-deprecated-declarations -Wno-unknown-pragmas -Wformat-security -D_FORTIFY_SOURCE=2 -fgnu89-inline -fvisibility=hidden -DS2N_EXPORTS -Wstack-protector -fstack-protector-all $(cat tests/features/GLOBAL.flags) $(cat tests/features/S2N_LINUX_SENDFILE.flags) -c -o tmp.o tests/features/S2N_LINUX_SENDFILE.c

Solution:

I'm not sure which behavior is preferable, but we should be consistent.
This would also be solved by just finishing the migration from make to cmake.

• Does this change what S2N sends over the wire? If yes, explain.
• Does this change any public APIs? If yes, explain.
• Which versions of TLS will this impact?

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links: Links to relevant RFC(s)
• Related Issues: Link any relevant issues
• Will the Usage Guide or other documentation need to be updated?
• Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
  • Will this change trigger SAW changes? Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
  • Should this change be fuzz tested? Will it handle untrusted input? Create a separate issue to track the fuzzing work.

Out of scope:

Is there anything the solution will intentionally NOT address?

[boquan-fang]

I observed that CMake wouldn't error on -Wimplicit-function-declaration flag, but Makefile will error on that. Check PR#4816 for details.