ctx.fragments.apple.single_arch_cpu returns wrong cpu of execution platform
#14291
Comments
|
cc: @kaylathar |
|
It seems the new apple platforms stuff will fix this, but it would be useful to have this fixed in some way in the 5.0 release. |
|
@meteorcloudy can you help get this triaged? Thanks! |
|
/cc @susinmotion for apple support Can you help look into this issue? |
|
Sadly this is a bit out of my field of expertise... @katre, do you know the timeline for this? |
|
I would have expected the platform mapping to work there, and cause the flag to be set properly. Is it possible to reproduce this without the Apple M1 hardware? |
gregestren
added
the
team-Configurability
|
Quickly looking I'm not sure if this is a platforms vs. Apple rules issue. But i think configurability can offer more input on the question as it now stands, so tagging |
gregestren
added
P2
…`ctx.fragments.apple` when building for darwin cpus (#749) Workaround for bazelbuild/bazel#14291. `ctx.fragments.apple.single_arch_cpu` is returning the default macos cpu for the host platform for tools while it should return the cpu of the execution platform.
|
@katre You can reproduce this from an Intel Mac (and probably Linux too): Create a Bazel workspace with the following files: my_binary.bzl def _impl(ctx):
ctx.actions.expand_template(
template = ctx.file._binary_template,
output = ctx.outputs.out,
substitutions = {"%CPU%": ctx.fragments.apple.single_arch_cpu},
is_executable = True,
)
return DefaultInfo(executable = ctx.outputs.out)
my_binary = rule(
_impl,
attrs = {
"out": attr.output(),
"_binary_template": attr.label(
allow_single_file = True,
default = Label("//:binary.sh.tpl"),
),
},
fragments = ["apple"],
)my_rule.bzl def _impl(ctx):
ctx.actions.run(
executable = ctx.executable.tool,
arguments = [ctx.outputs.out.path],
outputs = [ctx.outputs.out],
)
return DefaultInfo(files = depset([ctx.outputs.out]))
my_rule = rule(
_impl,
attrs = {
"out": attr.output(),
"tool": attr.label(
cfg = "exec",
executable = True,
),
},
fragments = ["apple"],
)binary.sh.tpl #!/bin/bash
# This is an %CPU% binary
echo %CPU% > "$1"BUILD load(":my_binary.bzl", "my_binary")
load(":my_rule.bzl", "my_rule")
my_binary(
name = "bin",
out = "bin.exe",
)
my_rule(
name = "a",
out = "a.out",
tool = ":bin",
)
platform(
name = "macos_arm64",
constraint_values = [
"@platforms//cpu:arm64",
"@platforms//os:macos",
],
)platform_mappings Build the bazel build -s --extra_execution_platforms=//:macos_arm64 aINFO: Analyzed target //:a (4 packages loaded, 19 targets configured).
INFO: Found 1 target...
SUBCOMMAND: # //:a [action 'Action a.out', configuration: 5456a5ed8cf67b8b3fed76a2365aa2f629f11b9ca3005aea194fdff9b065d983, execution platform: //:macos_arm64]
(cd /private/var/tmp/_bazel_admin/e5ea37a2992896f774f28a77d604884a/execroot/__main__ && \
exec env - \
bazel-out/darwin_arm64-opt-exec-C16863B4/bin/bin.exe bazel-out/darwin-fastbuild/bin/a.out)
# Configuration: 5456a5ed8cf67b8b3fed76a2365aa2f629f11b9ca3005aea194fdff9b065d983
# Execution platform: //:macos_arm64
Target //:a up-to-date:
bazel-bin/a.out
INFO: Elapsed time: 0.501s, Critical Path: 0.25s
INFO: 5 processes: 4 internal, 1 local.
INFO: Build completed successfully, 5 total actionsInspect the tool: cat bazel-out/darwin_arm64-opt-exec-C16863B4/bin/bin.exeThe expected contents of the |
|
Solid reproduction. I'll take a look, thanks. |
|
Okay, I've created a repo for the repro, and updated it to get more information, this is interesting: So the cpu and platform are as expected, it's just |
|
Okay, after far too much debugging it turns out to be fairly simple so far:
I tried explicitly setting |
|
Okay, there we go. I mis-read the code while debugging: I don't know if this will fix your original crash, but give it a try. If you think the value of Or send a PR, the code for this should be very similar. |
|
Note that |
|
I sent a PR here, please take a look: |
|
@bazel-io fork 5.1 |
… tools when host cpu and exec cpu are different Fixes bazelbuild#14291 Closes bazelbuild#14665. PiperOrigin-RevId: 425886938 (cherry picked from commit fce7ea8)
… tools when host cpu and exec cpu are different (#14751) Fixes #14291 Closes #14665. PiperOrigin-RevId: 425886938 (cherry picked from commit fce7ea8) Co-authored-by: Thi Doan <[email protected]>
…`ctx.fragments.apple` when building for darwin cpus (bazelbuild#749) Workaround for bazelbuild/bazel#14291. `ctx.fragments.apple.single_arch_cpu` is returning the default macos cpu for the host platform for tools while it should return the cpu of the execution platform.
Description of the problem / feature request:
When initiating a build from an M1 Mac with an Intel-based Mac RBE cluster (or vise versa), tools are built for the host platform instead of for the execution platform.
What underlying problem are you trying to solve?
Tools are built for the wrong platform can't run (natively).
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
From an M1 Mac:
platform_mappings
Add this declaration to the top-level BUILD file:
What operating system are you running Bazel on?
macOS Big Sur 11.6
What's the output of
bazel info release?release 6.0.0-pre.20211101.2
Any other information, logs, or outputs that you want to share?
The exec cpu value is coming from here https://github.com/bazelbuild/rules_swift/blob/5ea8f0a1a0b9372408a9d0a85f2cd81b6c9f510b/swift/internal/xcode_swift_toolchain.bzl#L643; a workaround is to replace it with the cpu from cc_toolchain:
cc_toolchaininstead of fromapple_fragmentrules_swift#694The text was updated successfully, but these errors were encountered: