An error occurred during the fetch of repository 'rbe_default': key "mac os x" not found in dictionary

[davidlee1435]

Hey folks,

I'm currently trying to run the examples in this repository. For context, I have a remote execution server running BuildGrid on an Amazon Linux image. I am using bazel_toolchains version 3.3.1.

After copying the example WORKSPACE and .bazelrc, I'm receiving this error message:

$ bazel clean --expunge && bazel build --config=remote //...
INFO: Starting clean.
Starting local Bazel server and connecting to it...
INFO: Invocation ID: b3a3aa84-307a-4642-91f7-33d0ae5bea1a
INFO: Options provided by the client:
  Inherited 'common' options: --isatty=1 --terminal_columns=90
INFO: Found applicable config definition common:remote in file /Users/davidlee/dev/examples/java-maven/.bazelrc: --spawn_strategy=remote --strategy=Javac=remote --strategy=Closure=remote --strategy=Genrule=remote --define=EXECUTOR=remote --remote_executor=grpc://ec2-3-101-14-83.us-west-1.compute.amazonaws.com:50051 --remote_instance_name=main --announce_rc --crosstool_top=@rbe_default//cc:toolchain --host_javabase=@rbe_default//java:jdk --javabase=@rbe_default//java:jdk --host_java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8 --java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8 --extra_execution_platforms=@rbe_default//config:platform --host_platform=@rbe_default//config:platform --platforms=@rbe_default//config:platform --extra_toolchains=@rbe_default//config:cc-toolchain
INFO: Call stack for the definition of repository 'rbe_default' which is a _rbe_autoconfig (rule definition at /private/var/tmp/_bazel_davidlee/69e0bb4508c054bbdc8964a6633bb9ad/external/bazel_toolchains/rules/rbe_repo.bzl:650:19):
 - <builtin>
 - /private/var/tmp/_bazel_davidlee/69e0bb4508c054bbdc8964a6633bb9ad/external/bazel_toolchains/rules/rbe_repo.bzl:1170:5
 - /Users/davidlee/dev/examples/java-maven/WORKSPACE:41:1
DEBUG: /private/var/tmp/_bazel_davidlee/69e0bb4508c054bbdc8964a6633bb9ad/external/bazel_toolchains/rules/rbe_repo.bzl:491:5: Bazel 3.0.0 is used in rbe_default.
ERROR: An error occurred during the fetch of repository 'rbe_default':
   key "mac os x" not found in dictionary
ERROR: While resolving toolchains for target //:java-maven: com.google.devtools.build.lib.packages.RepositoryFetchException: no such package '@rbe_default//config': key "mac os x" not found in dictionary
ERROR: Analysis of target '//:java-maven' failed; build aborted: com.google.devtools.build.lib.packages.RepositoryFetchException: no such package '@rbe_default//config': key "mac os x" not found in dictionary
INFO: Elapsed time: 2.919s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (2 packages loaded, 2 targets configured)

Has anyone else run into this issue before? If so, how did you resolve this?

[smukherj1]

It looks like you're running Bazel from a Mac. Mac (client) -> Linux (remote machine) builds aren't supported by these rules yet. I would suggest trying to run the rules from a Linux machine instead to fix this error.

[davidlee1435]

That makes sense, thanks! Are there any plans to support cross-operating system builds? If so, is there a timeline we could expect this by?

[smukherj1]

No plans to support cross-operating system builds in bazel-toolchains at the moment. However, if you're willing to contribute support I won't say no provided you can figure out how to test it 😃

[darl]

Is it something that changed recently?
This setup definitely worked for me some time ago (~6 month).

[ulfjack]

The underlying problem is that the rules look at the current OS to determine which configs to generate. I came up with a patch that allows manually overriding the auto-detection:
https://github.com/EngFlow/bazel-toolchains/tree/os-family-override

This probably doesn't work with Windows, but I was able to cross-build some things using a Linux cluster from a Mac laptop.

@smukherj1 I don't think anyone other than you can figure out how to test this in your CI.

[kevingessner]

@ulfjack Do you have a PR to get your override change merged? We'd definitely use it.