bazel build //... fails on OSX #226
Comments
|
This WFM on 0.25.2 |
|
Just tried installing command line tools for xcode 9 and it fixed the issue. So installing an older version of xcode seems to be a good workaround although it would be nice to get this issue fixed for newer xcode versions. |
|
I only have XCode 10.2.1 tools installed. Are you sure you're running Bazel 0.25.2? Another problem can happen if you have never run xcode-select. After that, I think Bazel should add libc++ (llvm/clang) rather than libstdc++ (gnu/gcc) to the link line. |
|
I am running in the same error with a fresh install of Bazel 0.28.1, Skylib 0.9.0 and the current master of rules_rust. I have both Xcode 10.3 and the CLI tools installed. Switching between either does not seem to make a difference. Unless someone has a solution/work around I'll try and look into this over the next few days. |
|
It seems Xcode is really needed, just the CLI tools does not suffice. Setting the path, deleting Bazel's local cache and rebuilding my target seems to resolve this for me. After that everything seems fine. |
Thanks. I downloaded Xcode and followed these command to fix the issue. Too bad I had to download the entire Xcode though... |
|
I got around this by using a custom cc toolchain, instead of relying on the host toolchain (this has the advantage that I can be sure I'm building with the same version of the same compiler on all platforms): # -- WORKSPACE --
http_archive(
name = "com_grail_bazel_toolchain",
url = "https://github.com/grailbio/bazel-toolchain/archive/0.5.zip",
sha256 = "33011cd77021017294d1982b48d0c3a081c777b9aad9a75f3e4eada0e10894d1",
strip_prefix = "bazel-toolchain-0.5",
)
load("@com_grail_bazel_toolchain//toolchain:deps.bzl", "bazel_toolchain_dependencies")
bazel_toolchain_dependencies()
load("@com_grail_bazel_toolchain//toolchain:rules.bzl", "llvm_toolchain")
llvm_toolchain(
name = "llvm_toolchain",
absolute_paths = True,
llvm_version = "9.0.0",
)
load("@llvm_toolchain//:toolchains.bzl", "llvm_register_toolchains")
llvm_register_toolchains()
# ... rest of rules_rust setup ...Instead of relying on Also chime in, I hit the exact same error as the OP reported. I'm on macOS 10.15.3 (Catalina) and I only have the command line tools installed, not Xcode.app: It's definitely a bug to continue to depend on passing |
|
Pinging this issue. It'd be nice to have the rules be able to fetch the things they needed to work. |
|
Hi, |
|
Unsure if it's related to the issue here but examples are currently broken as well: examples % bazel build //... |
|
In my case here's what seems to be happening. With hello world in src/hello.rs, bazel runs this: The key is the The error is this: That failure message, as far as I can tell, is coming from rustup. Let's see where the bazel/tools/cpp/unix_cc_configure.bzl line 391: There's no conditional around it, so it looks like every unix c++ builder (toolchain?) gets those flags. They can, however, be overridden. line 396 in that file: If I run this, the compilation magically succeeds: FWIW a Are we meant to be in configure_osx_toolchain? In my case I'm falling through to configure_unix_toolchain (if I set BAZEL_USE_XCODE_TOOLCHAIN=1 the build fails), which is where we end up with the unconditional -lstdc++. I'm guessing that xcode_locator is working for those who install full xcode (not just the command line tools) so that's why they're staying in configure_osx_toolchain rather than being fobbed off on configure_unix_toolchain? |
|
I should note that my inability to run xcode_locator is quite possibly my doing (or CorpEng's doing), and I'm not in a position to confirm/refute that. The takeaways are probably if xcode_locator fails, for whatever reason, failure to link against libstdc++ may result. Whether it makes sense to change from -lstdc++ to -lc++, and whether the unix toolchain is expected to be used at all on a mac, is well beyond my level of expertise. |
|
I'm having the same problem on macOS Monterey. |
|
I was having this issue on Big Sur, but downgrading Bazel from 4.2.2 to 4.1.0 fixed it. |
|
For folks experiencing |
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 |
|
Thanks! |
This update addresses bazelbuild/rules_rust#226, which was causing Anki builds to fail on macOS.
Seems to be because xcode removed libstdc++ (and replaced it with libc++) but we still depend on it. Here's the full error message:
The text was updated successfully, but these errors were encountered: