objc_library does not use the right C++ dialect when compiling .mm files

[camillol]

Description of the problem / feature request:

Let's say you have a project that uses C++ and Objective-C[++], and you want to use C++17. You pass --cxxopt=-std=c++17 when building. But your project depends on Abseil, and you start getting link errors where Objective-C++ .o files depend on missing symbols such as absl::string_view (which doesn't exist under C++17, since it just becomes an alias for std::string_view).

It turns out that objc_library is trying to build .mm files using std=gnu++11, even though you have requested a different C++ dialect. Using different C++ dialects for different files breaks Abseil (and probably other things).

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

I want to set the C++ dialect uniformly for the entire build, e.g. by putting --cxxopt=-std=c++17 in by .bazelrc, and I want it to apply to Objective-C++ code too.

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

A cc_binary depending on an objc_library containing an .mm file that uses absl::string_view; build with --cxxopt=-std=c++17.

What operating system are you running Bazel on?

macOS, targeting iOS.

What's the output of bazel info release?

release 3.7.1

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

• The first workaround one would try is to globally set the C++ dialect for Objective-C++ separately from that for plain C++.
  However, there is no command line argument to set options for Objective-C++ only (i.e. no --objcxxopt).
  Using --objccopt does not work either, because it tries passing the C++ options to play Objective-C files too, which fails.

• So we have to fall back on a much more cumbersome workaround, which is to set the option separately for each objc_library rule. But this is also not enough, because we run into the same problem with rule arguments as we do with command line options: no way of specifying separate options for .m and .mm. If there are targets containing both, we have to split them into separate targets.

  This works, but it's a pain. In MediaPipe's case, it also needs to include a patch for its TensorFlow dependency.

• The third possible workaround would be to replace objc_library with cc_library using copts = ["-x objective-c++", "-fobjc-arc"], but that requires renaming .mm files to .cc IIRC.

Related bugs

Issue #2268 is about the inability to supply a separate copts for Objective-C++ files only. Issue #5318 is a duplicate of it, with more activity. I am filing this as a separate issue because my goal is different (setting the C++ dialect globally); those issues just complicate the workaround.

[camillol]

It looks like there's a better workaround, which is to use --per_file_copt=.*\.mm\$@-std=c++17 globally.

[kkpattern]

We also encounter this problem. A --objcxxopt would be really helpful.

Thanks @camillol for the nice workaround.

[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.

[brentleyjones]

Not stale.

[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. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[jiawen]

Not stale.

While there's a workaround, it's not particularly satisfying.

[keith]

here's a pass at this #23858