Bazel uses /usr/bin/clang instead of /usr/bin/clang++ to link C++ code on FreeBSD?

[yesudeep]

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?

1. Perhaps use clang++/g++ for C++ code and clang/gcc for C code.
2. The two languages should use different rules as well: cc_library for C++ and c_library for C code.

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

❯ git clone https://github.com/google/cctz
...
❯ bazel test ...
...
ERROR: /usr/home/yesudeep/code/yesudeep/cctz/BUILD:165:10: Linking of rule '//:example3' failed (Exit 1) clang failed: error executing command /usr/bin/clang -o bazel-out/freebsd-fastbuild/bin/example3 bazel-out/freebsd-fastbuild/bin/_objs/example3/example3.pic.o bazel-out/freebsd-fastbuild/bin/libtime_zone.a ... (remaining 5 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
ld: error: undefined symbol: ceilf
>>> referenced by time_zone_impl.cc
>>>               time_zone_impl.pic.o:(ceil(float)) in archive bazel-out/freebsd-fastbuild/bin/libtime_zone.a
clang: error: linker command failed with exit code 1 (use -v to see invocation)
INFO: Elapsed time: 0.357s, Critical Path: 0.03s
INFO: 0 processes.
FAILED: Build did NOT complete successfully
//:cctz_benchmark                                                     NO STATUS
//:civil_time_test                                                    NO STATUS
//:time_zone_format_test                                              NO STATUS
//:time_zone_lookup_test                                              NO STATUS

FAILED: Build did NOT complete successfully

What operating system are you running Bazel on?

• FreeBSD 12.0-RELEASE

❯ uname -a
FreeBSD monalisa 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC  amd64

❯ /usr/bin/clang++ --version
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1)
Target: x86_64-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin

and

• GhostBSD 20.08.20 (FreeBSD 12.0-RELEASE based)

❯ uname -a
FreeBSD mevin 12.1-STABLE FreeBSD 12.1-STABLE GENERIC  amd64

❯ /usr/bin/clang++ --version
FreeBSD clang version 10.0.0 (git@github.com:llvm/llvm-project.git llvmorg-10.0.0-0-gd32170dbd5b)
Target: x86_64-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin

What's the output of bazel info release?

• FreeBSD

❯ bazel --version
bazel 3.3.0

and

• GhostBSD (FreeBSD 12.0-RELEASE based)

❯ bazel info release
release 3.4.1

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

❯ git remote get-url origin; git rev-parse master; git rev-parse HEAD
https://github.com/google/cctz
da5a52d91bf212a1f8c17f366ed8b947e2663d2a
da5a52d91bf212a1f8c17f366ed8b947e2663d2a

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?

I think the above should include the logs, but please ask if you
need anything else.

[yesudeep]

I think fixing this problem would allow quite a few C++ libraries to compile cleanly on FreeBSD/OpenBSD.

[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 2+ years. It will be closed in the next 14 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.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

[dbaileychess]

@bazelbuild/triage Can you look at this for google/flatbuffers? https://github.com/google/flatbuffers/blob/master/src/BUILD.bazel#L23-L28

[siepkes]

@bazelbuild/triage Would you consider re-opening this auto-closed issue? I'm not going to say Bazel is dead in the water on FreeBSD due to this issue but it does break a lot of stuff on FreeBSD...

[yesudeep]

IMHO, the most appropriate fix for this is to have 2 sets of rules: 1. cc_library, cc_binary, etc. (using clang++) and 2. c_binary, c_library, etc. (using clang)

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