`flag_if_supported("-std=c++YY")` seems to always fail with clang

[jonringer]

A long form report can be found here: dtolnay/cxx#952

cxx sets .flag_if_supports("-std=c++11") by default, yet this doesn't get passed to the underlying CC invocation:

Command "clang++" "-O0" "-fPIC" "-g" "-fno-omit-frame-pointer" "--target=x86_64-apple-ios" "-m64" "-mios-simulator-version-min=7.0" "-isysroot" "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator15.0.sdk" "-fembed-bitcode" "-Wall" "-Wextra" "-o" ".../cxx/target/x86_64-apple-ios/debug/build/cxx-ccd15dd18add3b1b/out/src/cxx.o" "-c" "src/cxx.cc" with args "clang++" did not execute successfully (status code exit status: 1).

Summary

On MacOS (maybe all clang installations), usage of the .flag_if_supported() method seems to always fail as clang emits a number of "unused arguments" warnings to stderr. Many of the options such as -fPIC don't get used with the flag_check command and thus clang emits many warnings even without an explicit -v being present. Since stderr is checked for potential failures, all invocations of flag_if_supported() seem to be omitted.

[dot-asm]

Not that I can claim that my tests were exhaustive, but I can't confirm that .flag_if_supported() is bound to fail on MacOS. I even fail to come up with a combination of flags that would qualify for unused-command-line-argument warning. The most common cause is -l flag combined with -c, but is_flag_supported() links an executable... Can you tell what's the failing combination? BTW, I wouldn't be surprised if the environment variables play a role here, so watch out even for that.

[jonringer]

I wouldn't be surprised if the environment variables play a role here, so watch out even for that.

What environment variables would possibly influence the build like that?

For more context, if I run cargo build, this all passes. It's only when running cmake + corrosion_import_crate() in cmake in which this seems to appear. The reason why I opened an issue here is that I can't find a meaningful difference between those two scenarios.

The failing command:
https://github.com/dtolnay/cxx/blob/746a369c6b38d6c2ce365d82c6e0fcd8664bb175/build.rs#L6-L12

[dot-asm]

What environment variables would possibly influence the build like that?

CFLAGS/CXXFLAGS... Maybe even IPHONEOS_DEPLOYMENT_TARGET?

if I run cargo build, this all passes.

In other words you can't confirm that .flag_if_supported() is bound to fail on MacOS either ;-)

I can't find a meaningful difference between those two scenarios.

There obviously is some. Unfortunately I can't tell. But when you figure it out, the question would be how to handle it. Would it be cc-rs's responsibility to work around the problem, or somebody else's. Formally one can say that cc-rs was shown to be self-consistent, and whatever happens is an external problem. But if maintainers will look at this differently, then one can wonder if unconditionally passing -Wno-unused-command-line-argument when compiling flag_check.c[pp] which clang would be justified. It would be sufficient, the question is if it would be the right thing to do given yet to be specified circumstances.

[jonringer]

I'll try to debug this further, and find the minimal difference between the failing environment and a successful build.

[seungillee]

Is there some update on this issue?

[thomcc]

I'd take a patch that passes -Wno-unused-command-line-argument, although someone should do the legwork to ensure -Wno-unused-command-line-argument itself is well-supported.

[seungillee]

Could you tell me a little bit detail about using -Wno-unused-command-line-argument patch? Does it mean I need to use custom build of cxx? Or is there a way to specify it in my Cargo.toml when defining cxx as dependency?

[thomcc]

I mean I'd accept a PR (sorry, "take a patch" is the pre-github phrasing), and then it would be in the next version of cc.

[seungillee]

Does that mean I need to wait until next version of cc is available?

[thomcc]

You'd also have to write the PR, and verify it won't cause issues. Or someone would.

[thomcc]

Basically: If someone writes a PR fixing this issue without introducing other issues, I would accept it. I believe the right approach for that probably involves -Wno-unused-command-line-argument.