Allow configuring different compilers for C and C++

[snowp]

Description of the problem / feature request:

Allow configuring separate compiler executables when targeting C and C ++respectively, and make this information accessible in Skylark (e.g. add it to the cpp fragment). Having them be declared by CC/CXX would be nice, but that might break a lot of stuff since CC is already used to configure the C++ compiler.

Feature requests: what underlying problem are you trying to solve with this feature?

From what I understand the cc_toolchain is supposed to configure both the C++ and C toolchain, but it only allows specifying one compiler executable. This means that in cases where one might want to use g++ as the C++ compiler, you will no longer be able to build C files (without providing a secondary toolchain? I'm a bit fuzzy here). This is a real problem, see for example envoyproxy/envoy#839. Envoy uses g++/clang++ instead of gcc/clang to work around #2840

Have you found anything relevant by searching the web?

Looked at the cpp fragment docs and asked around in IRC. Everything seems to assume that the compiler given to the cc_toolchain can handle both C++ and C.

If this seems like a reasonable idea I'm happy to attempt to get this working.

[snowp]

Quick proof of concept of what I was thinking: snowp@0672499

Would love to hear if this is something that'd be useful. @damienmg mind taking a look? or delegating to someone more appropriate

[benjaminp]

What's the problem with using always using gcc as the compiler? It's perfectly capable of compiling C++.

[snowp]

While gcc can compile C++ they're aren't the same: https://stackoverflow.com/questions/172587/what-is-the-difference-between-g-and-gcc

From what I understand it might be possible to configure gcc to do whatever g++ can do, but it seems once you're writing your own toolchains that being able to make use of the different features/defaults between gcc/g++ would be useful. The idea being that sometimes it's easier to point the C++ compiler straight at g++ instead of having to configure gcc to act like g++.

[benjaminp]

Yes, the linking behavior is slightly different, but in a crosstool, there isn't really any harm in explicitly writing the -lstdc++.

[snowp]

The issue that envoy ran into boiled down to the fact that gcc ignored -static-libstdc++ while g++ did not: #2840, so there's more to it then just +/- -lstdc++

From what I can tell there's enough differences between the two of them that being able to define them separately doesn't seem too unreasonable. While gcc could technically be configured to handle any C++ you throw at it seems weird to me that one could configure their project to use g++ and have it work perfectly until you include a single C file, at which point you have to redo your CROSSTOOLS because you have to use the same compiler between the languages. I don't think this is a huge blocker for anything, although it does seem like a quality of life kind of thing.

I'm not gonna spend too much time trying to get this in, it was mostly a big surprise that bazel made this so difficult (coming from e.g. cmake where one has distinct CC and CXX are distinct options). Happy to drop this if it goes against the intent of the CC toolchain.

[snowp]

To be clear: I'm arguing for giving people the option to specify a different C/C++ compiler, not claiming that it's necessary

[jmillikin-stripe]

There is no guarantee that the behavior of gcc and g++ is the same, even if they happen to be the same executable -- changing behavior based on argv[0] is a tradition in C-family compilers, and they don't always do so in ways that Bazel expects or can control.

Examples:

• gcc and g++ have different link-time behavior that can't be overridden with flags which prevents Bazel-built binaries from statically linking libstdc++. Envoy is planning to use a wrapper script around $CC that tries to invoke the correct compiler (possibly $CXX) based on flag inspection, which is unpleasant and fragile.
• clang -xc++ and clang++ have different include search paths which interferes with Bazel's strict header dependency checking.

I can't think of any other case where compiler configuration for two different languages would be represented with the same variables merely because one particular implementation is busybox-ish.

[lberki]

Yuck, the wrapper script in https://github.com/envoyproxy/envoy/pull/2631/files is awful.

Compiling with a different binary looks doable, but what about linking? Is the rule that the C++ compiler should be used if there is at least one object file that was built from C++?

[lberki]

(keeping this as P2 due to that wrapper script)

[jmillikin-stripe]

what about linking? Is the rule that the C++ compiler should be used if there is at least one object file that was built from C++?

This is the rule for GCC and probably for Clang. Note that a cc_library(srcs=["foo.o"]) might be C or C++ (and Envoy uses that for some C++ deps), so it might be best to default to the C++ linker for now until there's a better cc_import story.

[jmillikin-stripe]

Has there been any progress on separating C and C++ compiler options? The Envoy wrapper script still exists, and is becoming quite complex. We'd really like to get rid of it, but can't until this bug is fixed.

[hlopko]

Not much, but #6926 is scheduled for this quarter, so maybe in the near future.

[oquenchil]

what about linking? Is the rule that the C++ compiler should be used if there is at least one object file that was built from C++?

This is the rule for GCC and probably for Clang. Note that a cc_library(srcs=["foo.o"]) might be C or C++ (and Envoy uses that for some C++ deps), so it might be best to default to the C++ linker for now until there's a better cc_import story.

What do you need from cc_import to solve the issue described here?

[carlosgalvezp]

Any updates? This is still a problem, see e.g.: #11122

[hchsiao]

bazel-contrib/rules_foreign_cc#931 is also affected by this one.

In this case, the rule is using cc_common.get_tool_for_action(feature_configuration, action_name) to get the compiler.

https://github.com/bazelbuild/rules_foreign_cc/blob/0cf751c0533815747356bd3539d099015d556eb5/foreign_cc/private/cc_toolchain_util.bzl#L269-L276

The problem here is that get_tool_for_action() returns the same result no matter action_name set to ACTION_NAMES.c_compile or ACTION_NAMES.cpp_compile.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[CareF]

I think this is still an existing issue, unless someone determines that this is not going to be supported.

[RedwanFox]

@bazelbuild/triage still relevant

[matts1]

This has been fixed (assuming you use action_configs, and have configured them correctly, since without action configs you can't configure a seperate C and C++ tool).

I got it working in bazelbuild/rules_rust@a92de54

[fwalch]

@matts1 Do you have an example of a toolchain that has been configured with separate C and C++ tools? Looking at the env in bazelbuild/rules_rust@a92de54, I always got the same value for CC and CXX, so I assume the toolchains I tried were not configured correctly?

[matts1]

I'm working on an example right now, if you look at the commits to rules_cc over the next few days.

Tldr is to set one tool for the c_compile action and another for the other compile actions.

[matts1]

Also, I'll be doing a presentation at bazelcon in ~2 weeks on defining C++ toolchains, which may help.