make_tool fails on Mac #859
Comments
|
I'm looking at the exact same error on Mac OS Big Sur What I'd like to build using the rule |
|
0.6.0 does not seem to have this issue. |
|
Seeing the same issue on
If anyone finds a workaround or solution, please post here. |
|
For some reason rule_foreign_cc started to pass -undefined dynamic_lookup to the configure. That is wrong and cannot possibly work. Workaround for 0.7.1: |
|
@graywolf-at-work do you have any insights as to why this isn't failing in CI? Is this specific to Apple silicon macOS as that configuration isn't tested by CI due to lack of availability of any Apple Silicon machine in bazel's CI. |
|
I don't have m1, nor I am an expert on this project or bazel, but I would guess it's a combination of https://github.com/bazelbuild/rules_foreign_cc/blob/main/toolchains/BUILD.bazel#L104 and https://github.com/bazelbuild/rules_foreign_cc/blob/main/.bazelci/config.yaml#L18 . In other words, it's not being built as part of the CI. So it does not fail. |
Any update for that? I still get same error messages after patch applied |
|
Also seeing this on an up to date M1 Pro. |
|
As far as I know, none of the regular contributors or maintainers have access to an M1 mac and so we're reliant on contributions from the wider community to fix this up. PR's very welcome to fix any M1 specific issues. |
|
Happy to help fix things! Thanks for being so responsive on these issues. Would you be able to help me understand what's going wrong here so we can fix it together? load("@rules_foreign_cc//foreign_cc:defs.bzl", "configure_make")
filegroup(
name = "all_srcs",
srcs = glob(["**"]),
)
configure_make(
name = "capnp",
autoconf = True,
configure_in_place = True,
lib_source = ":all_srcs",
visibility = ["//visibility:public"],
) |
|
It would appear that the call to configure is incorrectly finding a successful compile for the function |
|
I see, that makes sense. I'm not too familiar with C toolchains, and the only thing I could really find was this: Though as you mentioned, it looks like Is there anything I can do to help debug why this is happening? |
|
Interestingly, the patch suggested by @graywolf-at-work seems to work! diff -urN a/foreign_cc/built_tools/make_build.bzl b/foreign_cc/built_tools/make_build.bzl
--- a/foreign_cc/built_tools/make_build.bzl 1969-12-31 19:00:00.000000000 -0500
+++ b/foreign_cc/built_tools/make_build.bzl 2000-01-01 00:00:00.000000000 -0000
@@ -71,6 +71,9 @@ def _make_tool_impl(ctx):
if absolute_ar == "libtool" or absolute_ar.endswith("/libtool"):
arflags.append("-o")
+ if os_name(ctx) == "macos":
+ non_sysroot_ldflags += ["-undefined", "error"]
+
env.update({
"AR": absolute_ar,
"ARFLAGS": _join_flags_list(ctx.workspace_name, arflags), |
Out of curiosity, what leads you to the conclusion that this is a M1 specific issue? I've hit this bug on normal, non-arm macbook. |
bazel CI is running tests on x86_64 macOS as part of the regular testing that is done. However I guess if you are also seeing it on x86_64 then this could be a OS or XCode version that is causing this issue then. |
|
https://buildkite.com/bazel/rules-foreign-cc/builds/3998#c472be5b-2981-4038-b49f-f3ffc6e2ef4a - looking at CI output CI is on macOS 11.6.1 and XCode 13. I suspect its the 11.6.1 that is causing this difference in experience. @philwo @Wyverald @meteorcloudy - we're potentially seeing specific breakages in builds here due to newer version of macOS behaving differently to what the test configuration is in CI. Given BigSur is now OS -2 are there any plans to update the CI runners to a newer version? |
|
That sounds about right. I'm on macOS 12.3.1 (21E258). |
|
Should we open a PR for this fix? |
Please do |
|
@jsharpe Yes, upgrading the macOS versions to the latest version is on our todo list, it should happen soon. |
|
@meteorcloudy Thanks Yun |
From the PR just opened it seems that the examples aren't building as expected anymore with the built make toolchain. I've opened #895 to track this as we should definitely address this. |
|
I think you might have overlook this message from me: #859 (comment) . I've already stated on Mar 7 that the CI passes because it's not build as part of the CI. |
|
Hi, has this issue been fixed? I'm still seeing this on MacOS 13.5 |
|
Can confirm this is also an issue on MacOS 14.1 so reopening. |
|
Note that I don't have an M1 Mac (Quad-Core Intel Core i5 instead) and this issue shows up |
|
I am hitting this issue on M2-based Mac (Sonoma 14.1) while using rules_foreign_cc v0.10.1 which includes the patch suggested above Also tried to use locally installed make/cmake with but it did not help. |
|
install xcode does help to resolve this, and don't forget to clean the bazel cache. |
|
This didn't help, @tangm @xocodergit any specific command to check version or path ? |
|
Can confirm the issue still exists, and is NOT solved by using Xcode (instead of Xcode command line tools): This is an x86 MacBook Pro, the issue is not related to Apple Silicon, but rather to OS version (?). |
|
Sigh, why are we still here after 2 years? The root cause of this issue was that bazelbuild/bazel#16414 was not merged to rules_cc, but only to rules_llvm and apple_support. Which removed the culprit
Filing bug with rules_cc now. |
|
@ashi009 Tysm! Worked for me |
|
@ashi009 thanks for the advice! |
I ran into more issues after fixing this. Most of the configure-make based projects won't work even with this patch in as they expect gnu-compatible ar instead of the darwin libtool. So still struggling with rules_cc, rules_foreign_cc and toolchains_llvm. |
I don't unfortunately; I don't often develop natively on macOS and previous attempts I've made to reproduce this I haven't run into the issue described; it seems very specific to a set of packages that are installed / aren't installed on the host and how the toolchain is configured. However I will state the same advice that I'll always give with regard to rules_foreign_cc; prefer to spend the effort you'd spend debugging issues with rules_foreign_cc on porting the project to native bazel BUILD files and submit those to the BCR; you'll benefit the wider ecosystem, achieving a more reliable scalable build. |
@gerilya The following worked for me: rules_foreign_cc_dependencies(
register_preinstalled_tools = True,
register_built_tools = False,
) |
Running
gives the error
I'm running on Mac (arm64) using bazel 4.2.2. Has anyone seen this issue before, or know how to fix it?
If there is no immediate fix, I would be interested in using
configure_makewithout having to buildmake_tool(for example, by using themakealready installed on my system, or usingninja). How would I do this?The text was updated successfully, but these errors were encountered: