Bazel 4.2.2: C fails to link on macOS x86_64 #14395
Comments
|
maybe bazelbuild/rules_rust#978? 4.2.2 includes #14319, which says "This will cause the values passed in the link_libs parameters to not get silently dropped on macOS 12 Monterey" - so I wonder if this just surfaced a problem in rules_rust |
|
Thanks for taking a look! I had assumed #14319 may have been related, but not sure how or in what capacity.
I'm on Big Sur. |
|
Do you have a reproduction that does not involve rust? |
|
Similar problem has been reported elsewhere.
Consensus seems to be that I'm not sure where the flags come from, but I know they are put into the failing command at: As an experiment I tried replacing the arg with the apparent new version, and the issue was resolved. fixed_link_args = [x for x in link_args if x != "-lstdc++"]
fixed_link_args.append("-lc++")
rustc_flags.add_joined("--codegen", fixed_link_args, join_with = " ", format_joined = "link-args=%s")Removing the line altogether also worked (simple program though, so lib may just not have been needed). |
|
Did some more digging and found where Rule definition is at bazel/tools/cpp/cc_configure.bzl Lines 145 to 179 in b4b0c32 With the more limited search range I was able to identify 2 likely places bazel/tools/cpp/cc_toolchain_config.bzl Line 398 in c579155 bazel/tools/cpp/unix_cc_configure.bzl Line 403 in c579155 Argument ordering has me thinking |
|
Note for macOS users with Xcode installed, you have to set I looked into this a bit in clang. So what seems to be the issue is that You can see the arg passed to the linker here is different from what I passed. The issue in this case Based on this comment https://github.com/llvm/llvm-project/blob/11a46b174923a2509ac620bc8ff621ecdf6135b6/clang/lib/Driver/ToolChains/Darwin.cpp#L872-L876 this has been invalid for a long time. It looks like Here's a patch to fix this that I think is safe: #14542 Can folks try the bazel built with my branch to verify? It does fix the repro case above. |
This flag has been invalid seemingly since macOS 10.9 from 2013. By default clang remaps this back to -lc++, but if your linkopts pass -nodefaultlibs this is not the case, in which case this invalid flag fails the link. This happened for rust builds where the rust driver passes this flag intentionally. For more info see bazelbuild#14395 (comment)
This flag has been invalid seemingly since macOS 10.9 from 2013. By default clang remaps this back to -lc++, but if your linkopts pass -nodefaultlibs this is not the case, in which case this invalid flag fails the link. This happened for rust builds where the rust driver passes this flag intentionally. For more info see #14395 (comment) Fixes google/cargo-raze#247 #14395 bazelbuild/rules_rust#226 Closes #14542. PiperOrigin-RevId: 424588734
This flag has been invalid seemingly since macOS 10.9 from 2013. By default clang remaps this back to -lc++, but if your linkopts pass -nodefaultlibs this is not the case, in which case this invalid flag fails the link. This happened for rust builds where the rust driver passes this flag intentionally. For more info see bazelbuild#14395 (comment) Fixes google/cargo-raze#247 bazelbuild#14395 bazelbuild/rules_rust#226 Closes bazelbuild#14542. PiperOrigin-RevId: 424588734 (cherry picked from commit 8b60c90)
This flag has been invalid seemingly since macOS 10.9 from 2013. By default clang remaps this back to -lc++, but if your linkopts pass -nodefaultlibs this is not the case, in which case this invalid flag fails the link. This happened for rust builds where the rust driver passes this flag intentionally. For more info see #14395 (comment) Fixes google/cargo-raze#247 #14395 bazelbuild/rules_rust#226 Closes #14542. PiperOrigin-RevId: 424588734 (cherry picked from commit 8b60c90) Co-authored-by: Keith Smiley <keithbsmiley@gmail.com>
|
We can close this one now as the fixes have been merged into bazel 5.1 |
Description of the problem / feature request:
C fails to link on macOS x86_64. This works fine on Bazel 4.2.1 and so I would consider this a regression.
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
I have a repository which contains a reproduction for the issue.
https://github.com/uhthomas/bazel-issue-14395
The project builds okay with Bazel 4.2.1.
What operating system are you running Bazel on?
What's the output of
bazel info release?Have you found anything relevant by searching the web?
No.
Any other information, logs, or outputs that you want to share?
The text was updated successfully, but these errors were encountered: