--host_cxxopt and --cxxopt are passed to the compiler also for .c files on Windows

[foxandi]

Description of the problem / feature request:

Since Bazel 5.0.0 --host_cxxopt and --cxxopt are passed to compilers compiling .c files on Windows.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Use the autoconfigure toolchain to build (with -s) a .c file in Windows. Set --host_cxxopt and --cxxopt in the .bazelrc and see in the compiler call the passed opts from the .bazelrc. Doing the same on Linux show, that the opts here are not passed.

What operating system are you running Bazel on?

Windows 10 Enterprise (Version 10.0.19042 Build 19042)

What's the output of bazel info release?

release 5.0.0

Have you found anything relevant by searching the web?

#14005
#14131

Any other information, logs, or outputs that you want to share?

This commit 861584c introduced case insensity for files types on Windows

bazel/src/main/java/com/google/devtools/build/lib/rules/cpp/CppFileTypes.java

Line 28 in 88499f6

private static final OsPathPolicy OS = OsPathPolicy.getFilePathOs();

The change also leads to .c files under Windows match to C_SOURCE (.c extension) and CPP_SOURCE (.C extension)

bazel/src/main/java/com/google/devtools/build/lib/rules/cpp/CppFileTypes.java

Lines 33 to 34 in 88499f6

	public static final FileType CPP_SOURCE =
	FileType.of(".cc", ".cpp", ".cxx", ".c++", ".C", ".cu", ".cl");

Which results in passing cxxopt for .c files

bazel/src/main/java/com/google/devtools/build/lib/rules/cpp/CcCompilationHelper.java

Lines 1605 to 1610 in 88499f6

	if (CppFileTypes.CPP_SOURCE.matches(sourceFilename)
	|| CppFileTypes.CPP_HEADER.matches(sourceFilename)
	|| CppFileTypes.CPP_MODULE_MAP.matches(sourceFilename)
	|| CppFileTypes.CLIF_INPUT_PROTO.matches(sourceFilename)) {
	flagsBuilder.addAll(config.getCxxopts());
	}

[meteorcloudy]

Maybe this is a similar bug that should be fixed like edfe2a1?

[meteorcloudy]

/cc @buildbreaker2021

[kkpattern]

We also encounter this problem. Unfortunately this causes us to not be able to compile Android on windows. Which is a major block for our project. Is there a rough estimate of when this will be fixed? Or is there any way we can workaround this? Thanks.

[oakad]

The worst thing here is that this issue is not even particularly complicated, even with WindowsOsPathPolicy rework included (the right thing to do: support for case sensitive directories on Windows 10+ will solve a lot of problems). Yet, it breaks a whole lot of plain C libraries on Windows putting a big question mark on Bazel's viability in general.

Which is a pity.

[kkpattern]

The worst thing here is that this issue is not even particularly complicated, even with WindowsOsPathPolicy rework included (the right thing to do: support for case sensitive directories on Windows 10+ will solve a lot of problems). Yet, it breaks a whole lot of plain C libraries on Windows putting a big question mark on Bazel's viability in general.

Which is a pity.

Currently, you can workaround this by replacing --cxxopt with --per_file_copt=.*\.cpp\$@.

But I agree that it's very confusing why this issue is a feature request and is P4.

[oakad]

It won't work for flags which are set in the actual BUILD files. The primary issue here, is that bazel offers no way to say "this file is plain C" explicitly. So, in a project with several dozens of third party dependencies a lot of patching and testing is needed to get anywhere with Bazel v5.

Bazel v4 sort of works, but then it can not be used with VS2022 due to another open issue.

[kkpattern]

Bazel v4 sort of works, but then it can not be used with VS2022 due to another open issue.

I thought this is not a problem for a msbuild based toolchain because msbuild only gives a warning? For us, it's a block issue because we're doing android cross compile on Windows and pass C++ flag to C compile simply failed.

Another interesting workaround is that we found somehow the C++ flags defined in toolchain won't be passed to C targets. So we end up moving the C++ flags to toolchain. But yeah it's lucky for us to be able to workaround this bug. For some complex project this may not work.

[oakad]

VS2022 is broken pretty badly, we had to go back to VS2019/bazel v4 for now. We may figure something out going forward; possibly by making all sources C++ compatible (this appears to be the best option on the cost/benefit scale).

Still, not nice.

[meteorcloudy]

@oquenchil This issue seems to have wide user impact on Windows. Is it caused by starlarkfifying the cc rules? Do you know which exact change caused this and how hard is it to fix this?

[kkpattern]

@meteorcloudy Looks like is caused by #14005. The .c extension is matched with .C cause bazel treat it as a C++ source. I think this can be fixed like edfe2a1 . I understand bazel team has many things to do and may not have the capacity to fix this. If you have the bandwidth to review a PR I can give this a try.

[meteorcloudy]

Not sure why .c and .C should mean different file types on Windows because file names are already case insensitive. Is this a Linux convention? Can you just change files with .C to .cpp?
But given we are already making an exception in edfe2a1, a PR to fix this sounds plausible, @oquenchil @comius should decide eventually.

[kkpattern]

Can you just change files with .C to .cpp?

We don't actually have any .C files. I think it's bazel that treated all .c files as .C files causing the problem.

[oakad]

@meteorcloudy Also see #15550 for some further info.

[Danvil]

Any progress on this issue? Bazel cannot compile C targets under Windows anymore since version 5. I don't think this warrants classification as a "feature request" or "P4".

[oakad]

Bazel can compile things on Windows, it just requires jumping through ugly loops with --per_file_copt= and possibly some patching.

But yes, this issue is bad and the lack of proper support for case sensitive abilities of NTFS is also unfortunate - that is, bazel would have worked fine on Windows with some extra configs if not for the rather stupid case forcing inside the Windows path resolver.

[Danvil]

From the documentation: --cxxopts: This is similar to --copt, but only applies to C++ compilation, not to C compilation or linking. In obvious contradiction bazel 5.3.2 passes --cxxopts arguments to C files. This is clearly a bug and not a "feature request". @oquenchil

I find if concerning that something that elementary is broken in bazel and swiped under the rug.

[kalmard0]

This bug is still causing significant problems in a project, forcing us to use an old bazel version which causes further compatibility issues and surfaces other bugs without fixes. Will it ever be looked at?

[oakad]

It's almost like Windows is not an important OS for developers any more. :-D

Yet, Windows is still the most used developer OS by a huge margin.

[meteorcloudy]

@oquenchil I think this shouldn't be a P4 issue, can you take a look?

If anyone has a fix for this, a PR is also very welcome!

[kkpattern]

Hi, I've created a PR. It's basically learned from edfe2a1 . I'm not very familiar to java actually, so please tell me if I did anything wrong. I've tested it on my environment and added a test.

[FaBrand]

Created the referenced Cherrypick @kkpattern Any objections agains the attempt?

[kkpattern]

Created the referenced Cherrypick @kkpattern Any objections agains the attempt?

Not at all😃.

[aaron-michaux]

Why is this closed? Observed in the latest 5.x and 6.x builds.

This is C code! sign.c is a C source file! --host_cxxopt=-std=c++17 causes -std=c++17 to be passed to C compilation!!!

/home/.../.cache/bazel/_bazel_build/install/a09dbb90c658248f08f9aa0eba11997d/process-wrapper '--timeout=0' '--kill_delay=15' '--stats=/home/.../.cache/bazel/_bazel_build/36f2a9693014a18078cf75940b43707b/sandbox/processwrapper-sandbox/114/stats.out' \

/usr/bin/gcc-9 -MD -MF bazel-out/k8-dbg-gcc/bin/external/boringssl/_objs/crypto/sign.pic.d \
   '-frandom-seed=bazel-out/k8-dbg-gcc/bin/external/boringssl/_objs/crypto/sign.pic.o' \
   '-DBAZEL_CURRENT_REPOSITORY="boringssl"' \
   -iquote external/boringssl -iquote bazel-out/k8-dbg-gcc/bin/external/boringssl \
   -isystem external/boringssl/src/include \
   -isystem bazel-out/k8-dbg-gcc/bin/external/boringssl/src/include \
   '-std=c++17' \ # WUHT?????
   -g -O0 -fno-omit-frame-pointer -fPIC -fno-canonical-system-headers \
   '-fdiagnostics-color=always' -Wa,--noexecstack -Wall -Werror '-Wformat=2' \
   -Wsign-compare -Wmissing-field-initializers -Wwrite-strings -Wshadow \
   -fno-common '-D_XOPEN_SOURCE=700' '-std=c11' -Wmissing-prototypes \
   -Wold-style-definition -Wstrict-prototypes -c external/boringssl/src/crypto/evp/sign.c \
   -o bazel-out/k8-dbg-gcc/bin/external/boringssl/_objs/crypto/sign.pic.o

[meteorcloudy]

6.3.0 should contain the fix? #18552

[kkpattern]

I did a simple test. When compile with MSVC with --cxxopt=/std:c++17, bazel 5.1.1 added the flag to a C source file:

C:\...\cl.exe ... -D__TIME__="redacted" /std:c++17 ... /c hello.c
                                         ^^^^^^^^^

while bazel 6.3.2 didn't:

C:\...\cl.exe ... -D__TIME__="redacted" ... /c hello.c

[aaron-michaux]

I'm using Ubuntu 22.04... so I'm seeing the problem on Linux. Given that we're not using Bzlmod (because of incompatibilities), it's possible that I have a dependency of a dependency that's getting an old version of cc_tools or something. It's frustrating because it my build is broken because of two rather trivial bugs that look like they're in bazel. (Where does @local_config_cc come from, after all???)