Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
yesudeep opened this issue Aug 30, 2020 · 7 comments
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-Rules-CPP Issues for C++ rules type: bug

Comments

@yesudeep
Copy link
Contributor

yesudeep commented Aug 30, 2020

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 ([email protected]: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
Copy link
Contributor Author

yesudeep commented Aug 30, 2020

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

@oquenchil oquenchil added P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-CPP Issues for C++ rules type: bug labels Sep 2, 2020
@oquenchil oquenchil changed the title [BUG] Bazel uses /usr/bin/clang instead of /usr/bin/clang++ to link C++ code on FreeBSD? Bazel uses /usr/bin/clang instead of /usr/bin/clang++ to link C++ code on FreeBSD? Nov 19, 2020
@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label Apr 12, 2023
@github-actions
Copy link

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
Copy link

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!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 28, 2023
@dbaileychess
Copy link

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

@siepkes
Copy link
Contributor

siepkes commented Jul 26, 2023

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

@sgowroji sgowroji reopened this Jul 26, 2023
@sgowroji sgowroji removed the stale Issues or PRs that are stale (no activity for 30 days) label Jul 26, 2023
@yesudeep
Copy link
Contributor Author

yesudeep commented Aug 5, 2023

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)

Copy link

github-actions bot commented Oct 9, 2024

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.

@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label Oct 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-Rules-CPP Issues for C++ rules type: bug
Projects
None yet
Development

No branches or pull requests

5 participants