Description of the problem / feature request:

Apparently, Bazel uses /usr/bin/clang instead of /usr/bin/clang++ to compile/link C++ code. I'm not sure whether this is intentional, but the behavior for clang is different from clang++ resulting in subtle problems at compile/link time:

❯ /usr/bin/clang -o bazel-out/freebsd-fastbuild/bin/time_zone_lookup_test '-Wl,-rpath,$ORIGIN/_solib_freebsd/' -Lbazel-out/freebsd-fastbuild/bin/_solib_freebsd bazel-out/freebsd-fastbuild/bin/_objs/time_zone_lookup_test/time_zone_lookup_test.pic.o -llibtime_Uzone -llibcivil_Utime -lexternal_Scom_Ugoogle_Ugoogletest_Slibgtest_Umain -lexternal_Scom_Ugoogle_Ugoogletest_Slibgtest -pthread -Wl,-S -lstdc++ -Wl,-z,relro,-z,now -no-canonical-prefixes
ld: error: bazel-out/freebsd-fastbuild/bin/_solib_freebsd/liblibtime_Uzone.so: undefined reference to ceilf
clang: error: linker command failed with exit code 1 (use -v to see invocation)

❯ /usr/bin/clang++ -o bazel-out/freebsd-fastbuild/bin/time_zone_lookup_test '-Wl,-rpath,$ORIGIN/_solib_freebsd/' -Lbazel-out/freebsd-fastbuild/bin/_solib_freebsd bazel-out/freebsd-fastbuild/bin/_objs/time_zone_lookup_test/time_zone_lookup_test.pic.o -llibtime_Uzone -llibcivil_Utime -lexternal_Scom_Ugoogle_Ugoogletest_Slibgtest_Umain -lexternal_Scom_Ugoogle_Ugoogletest_Slibgtest -pthread -Wl,-S -lstdc++ -Wl,-z,relro,-z,now -no-canonical-prefixes

The first command is what Bazel uses for purely C++ code on my FreeBSD system and the latter is what it should use. The only difference is clang++ instead of clang.

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

Perhaps use clang++/g++ for C++ code and clang/gcc for C code. The problem is very likely rules_cc using clang instead of clang++ as the C++ compiler in its toolchain definition. AFAIK, clang is the C compiler driver, not the C++ compiler driver. The two languages should use different rulesets as well: cc_library, cc_binary for C++ and c_library, c_binary for C code. AFAIK, C and C++ aren't the same.

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

Compile anything using googletest on FreeBSD.

What operating system are you running Bazel on?

• FreeBSD 14-CURRENT amd64.

What's the output of bazel info release?

>> bazel info release
release 6.0.0-2023-01-01 (@e724a5a)

If bazel info release returns "development version" or "(@Non-Git)", tell us how you built Bazel.

Replace this line with your answer.

What version of rules_cc do you use? Can you paste the workspace rule used to fetch rules_cc? What other relevant dependencies does your project have?

• MODULE.bazel

bazel_dep(name = "rules_cc", version = "0.0.2")
bazel_dep(name = "googletest", version = "1.11.0")

What Bazel options do you use to trigger the issue? What C++ toolchain do you use?

No custom options. The default toolchain used for freebsd.

Have you found anything relevant by searching the web?

Yes, apparently, everybody including me was getting around this by adding -lm linker flags until it was noticed that /usr/bin/clang is being used instead of /usr/bin/clang++ to link C++ code. Here's an example from the Bazel source tree.

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

• This was previously filed at: Bazel uses /usr/bin/clang instead of /usr/bin/clang++ to link C++ code on FreeBSD? bazel#12023 for FreeBSD 12.0
• Other issues: Linker error compiling with clang on linux google/googletest#3878 The -lm flags were added to googletest as a work around, but I'm not sure it is the correct solution. This needs to be fixed by separating cc_* from c_*, and by using clang++ for C++ and clang for C code.