cmake: Add fail pattern to `try_append_cxx

hebasto commented at 9:14 pm on December 10, 2025: member

This PR addresses scenarios where the build environment, such as OSS-Fuzz, provides the -Wno-error=unknown-warning-option flag, which undermines our use of -Werror when checking compiler flags.

To reproduce the issue on the master branch @ c1f0a89d9caeb62a0a5f3462b454746941e626e6:

0$ env CXX=clang++ CC=clang CXXFLAGS="-Wno-error=unknown-warning-option" cmake -B build 2>&1 | grep WDUPLICATED_BRANCHES
1-- Performing Test CXX_SUPPORTS__WDUPLICATED_BRANCHES
2-- Performing Test CXX_SUPPORTS__WDUPLICATED_BRANCHES - Success

This output shows that the -Wduplicated-branches flag is incorrectly treated as recognised by the compiler.

Noticed while working on the migration to Ubuntu 24.04 in OSS-Fuzz.

hebasto added the label Build system on Dec 10, 2025

DrahtBot commented at 9:14 pm on December 10, 2025: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/34047.

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

in cmake/module/TryAppendCXXFlags.cmake:67 in c8e51e6684

63@@ -64,7 +64,7 @@ function(try_append_cxx_flags flags)
64   set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
65   set(CMAKE_REQUIRED_FLAGS "${flags_as_string} ${working_compiler_werror_flag}")
66   set(compiler_result CXX_SUPPORTS_${id_string})
67-  check_cxx_source_compiles("${source}" ${compiler_result})
68+  check_cxx_source_compiles("${source}" ${compiler_result} FAIL_REGEX [=[\\[-Wunknown-warning-option\\]]=])

maflcko commented at 8:08 am on December 11, 2025:

i don’t understand how this could lead to issues. If someone passes w-no-error during configure, it will also be present during build, and the build should pass, no?

What is the issues that this is trying to fix?

What are the steps to reproduce?

hebasto commented at 1:07 pm on December 11, 2025:

The PR description has been updated with the steps to reproduce the issue.

maflcko commented at 3:50 pm on December 11, 2025:

This output shows that the -Wduplicated-branches flag is incorrectly treated as recognised by the compiler.

Yes, but this is what the user asked for by setting -Wno-error=unknown-warning-option?

I don’t think we should add code to silently undo switches that the user turned on.

Maybe I am missing something obvious, but I don’t see the risk or the downside of just leaving this as-is.

Noticed while working on the https://github.com/google/oss-fuzz/pull/14457 to Ubuntu 24.04 in OSS-Fuzz.

It seems unrelated to the migration, so I think it would be best to drop it there.

hebasto commented at 4:16 pm on December 11, 2025:

This output shows that the -Wduplicated-branches flag is incorrectly treated as recognised by the compiler.

Yes, but this is what the user asked for by setting -Wno-error=unknown-warning-option?

I don’t think we should add code to silently undo switches that the user turned on.

I don’t believe the user is asking the internal function to produce a false positive.

fanquake commented at 4:37 pm on December 11, 2025:

It seems unrelated to the migration, so I think it would be best to drop it there.

Yea, this is unrelated to the migration (already present in our oss-fuzz builds).

I don’t think we should add code to silently undo switches that the user turned on.

Agree. Having the build system try and second-guess what a user is trying to do, by negating certain flags being passed, is unexpected, and a complete can of worms.

hebasto commented at 4:44 pm on December 11, 2025:

This change neither “undo switches that the user turned on” nor “negating certain flags being passed”.

It is clear to see that the code is compiled with all flags passed by the user.

What is really unexpected that the build system uses flags unsupported by the compiler.

fanquake commented at 4:49 pm on December 11, 2025:

(this is also missing inline documentation)

hebasto commented at 5:06 pm on December 11, 2025:

Thanks! An inline explanatory comment has been added.

boxtob commented at 10:35 pm on December 16, 2025:

Technically it does negate the switch but the result/outcome is the same as already mentioned by @fanquake and @maflcko.

Expected behavior:

0$ env CXX=clang++ CC=clang CXXFLAGS="-Wno-error=unknown-warning-option" cmake -B build 2>&1 | grep WREALLY_UNKNOWN_WARNING
1-- Performing Test CXX_SUPPORTS__WREALLY_UNKNOWN_WARNING
2-- Performing Test CXX_SUPPORTS__WREALLY_UNKNOWN_WARNING - Success

Non expected behavior:

0$ env CXX=clang++ CC=clang CXXFLAGS="-Wno-error=unknown-warning-option" cmake -B build 2>&1 | grep WREALLY_UNKNOWN_WARNING
1-- Performing Test CXX_SUPPORTS__WREALLY_UNKNOWN_WARNING
2-- Performing Test CXX_SUPPORTS__WREALLY_UNKNOWN_WARNING - Failed

It is NOT expected behavior because the user/caller expects that the “REALLY_UNKNOWN_WARNING” flag will NOT cause an error.

hebasto force-pushed on Dec 11, 2025

cmake: Add fail pattern to `try_append_cxx_flags`

This change addresses scenarios where the build environment, such as
OSS-Fuzz, provides the `-Wno-error=unknown-warning-option` flag, which
undermines our use of `-Werror` when checking compiler flags.

c8d9e653cd

hebasto force-pushed on Dec 11, 2025

DrahtBot added the label CI failed on Dec 11, 2025

DrahtBot removed the label CI failed on Dec 11, 2025

maflcko added the label DrahtBot Guix build requested on Dec 12, 2025

DrahtBot commented at 11:35 pm on December 14, 2025: contributor

Guix builds (on x86_64) [untrusted test-only build, possibly unsafe, not for production use]

File	commit 938d7aacabd0bb3784bb3e529b1ed06bb2891864(master)	commit b1a03702ad6f3d67f10c8aee91e8fbc2a09d1ddb(pull/34047/merge)
*-aarch64-linux-gnu-debug.tar.gz	`09b86039bfc0c3e5...`	`3f56edb340be094f...`
*-aarch64-linux-gnu.tar.gz	`a41e664d6a9a7418...`	`e4a1d3f65304518d...`
*-arm-linux-gnueabihf-debug.tar.gz	`2fdd7ce3feda5dd8...`	`153f569e1c5364eb...`
*-arm-linux-gnueabihf.tar.gz	`862b2bc06e6cb336...`	`d37b500b3cad55c8...`
*-arm64-apple-darwin-codesigning.tar.gz	`311147e6c0b0812b...`	`900a9136ab0a484c...`
*-arm64-apple-darwin-unsigned.tar.gz	`9aada5283bae7989...`	`b98382cf62bbf9cd...`
*-arm64-apple-darwin-unsigned.zip	`078da360232c1ffe...`	`92a905df35ca5e08...`
*-powerpc64-linux-gnu-debug.tar.gz	`3e59d9a07cf0af8d...`	`3ea595564045e8b8...`
*-powerpc64-linux-gnu.tar.gz	`65e8a5983da133e4...`	`72cf7c0d5ea4fe2b...`
*-riscv64-linux-gnu-debug.tar.gz	`698decb6d1b72dd9...`	`40db9b8a65c1f009...`
*-riscv64-linux-gnu.tar.gz	`86af23a128c6e1ef...`	`de14ce46f5674dc4...`
*-x86_64-apple-darwin-codesigning.tar.gz	`62a690640c330629...`	`36b3438fa74ca131...`
*-x86_64-apple-darwin-unsigned.tar.gz	`96f4eeee89643f46...`	`52f05e7ef7fb46f6...`
*-x86_64-apple-darwin-unsigned.zip	`37b4e6d613c18b21...`	`fb78c15bc08f51d7...`
*-x86_64-linux-gnu-debug.tar.gz	`2a82a685d682bec0...`	`00a413b74a348930...`
*-x86_64-linux-gnu.tar.gz	`83d65a2b9ede1d1e...`	`8937436a800f2514...`
*.tar.gz	`cff4d7c15a6dc425...`	`643b85e41b75f5ef...`
SHA256SUMS.part	`358b54f54ccbebb1...`	`11919b74e0c95fa6...`
guix_build.log	`efeb0a71eec4679a...`	`e186a46c1fe907df...`
guix_build.log.diff		`b56d0394c2a7a655...`

DrahtBot removed the label DrahtBot Guix build requested on Dec 14, 2025

cmake: Add fail pattern to try_append_cxx_flags #34047

Code Coverage & Benchmarks

Reviews

Guix builds (on x86_64) [untrusted test-only build, possibly unsafe, not for production use]

cmake: Add fail pattern to `try_append_cxx_flags` #34047