Subject: uname -m on M1 MacBook returns arm64

From: Joe Schafer <[email-masked]>
Date: Tue, 4 Jan 2022 09:16:33 -0800

Hello,

I'm a big fan of this project. It's *lot* easier than trying to figure
out other Bazel CC toolchains.

One of my teammates ran into a curious error on an M1 Macbook using
the latest bazel-zig-cc.

    cc/toolchain/defs.bzl", line 219, column 70, in _zig_repository_impl
    zig_include_root  =
repository_ctx.attr.host_platform_include_root[host_platform]
    Error: key "macos-arm64" not found in dictionary

I traced this to toolchain/defs.bzl [1] which uses `uname -m` to get
the architecture. It looks like bazel-zig-cc only supports aarch64 but
M1 Macs return arm64.

What's really spooky is that bazel-zig-cc worked on my M1 mac but it
didn't work for two other devs on my team also on M1 macs; they got
the above error.

I was able to work around the problem with the following steps:
https://gist.github.com/jschaf/c9be10d806020087680310e49f6e2072.

- Uploaded all zig SDKs to my own hosting. I had to use my own hosting
to create macos-arm64 which is really just a copy of maco-aarch64 but
I had to change the folder name to match the archive name.

- Added "macos-arm64" to host_platform_include_root, similar to "macos-aarch64".

I'm by no means a Bazel toolchain expert, but I would have thought
there's a better way to get the host platform architecture than by
shelling out to uname. Appears that there's not [2] but that answer is
from 2017. Maybe platforms provide a way out [3]?

[1]: https://git.sr.ht/~motiejus/bazel-zig-cc/tree/main/item/toolchain/defs.bzl#L210
[2]: https://stackoverflow.com/a/45029999/30900
[3]: https://github.com/bazelbuild/rules_go/blob/master/go/private/go_toolchain.bzl#L95

---

From: Motiejus Jakštys <[email-masked]>
Date: Tue, 4 Jan 2022 20:01:42 +0100

> didn't work for two other devs on my team also on M1 macs; they got

Hi, Joe,

that's interesting indeed. I don't have an M1 mac, nor know anyone
with M1 mac, to test this "more closely".

> from 2017. Maybe platforms provide a way out [3]?

Re [3]: looks like `declare_toolchains` is an external function, and it
accepts `host` as a parameter, which should be set by the caller? If so,
I am not following how that would help.

If you can dig in for more information why `uname -m` returns arm64 vs
aarch64 (OSX minor version? something else?). If there is no other way
out, I would be OK to for an internal workaround to map darwin/arm64 to
darwin/aarch64 during download, provided it's the only problem 

Is downloading the toolchain the only problem? Once you add that
workaround, does it keep working as one would expect?

Motiejus

---

From: Joe Schafer <[email-masked]>
Date: Thu, 6 Jan 2022 14:43:28 -0800

> If you can dig in for more information why `uname -m` returns arm64 vs
aarch64 (OSX minor version? something else?)

I think I figured it out. It depends on whether the Bazel binary is an amd64
or arm64 binary. I installed the amd64 version Bazel first on my team before
arm64 was available. macOS runs the amd64 binary and propagates the
architecture down the call chain, including the subshell to uname. I can
confirm by running uname under x86_64 emulation with:

    arch -x86_64 uname -m
    x86_64

So I think this package will not work for an M1 mac running an arm64 version
of Bazel. I think an internal translation from arm64 to aarch64 is likely the
easiest approach.

Yep, as long as both the host_platform_sha256 and
host_platform_include_root dictionaries account for arm64.

---

From: Motiejus Jakštys <[email-masked]>
Date: Fri, 7 Jan 2022 20:10:43 +0100

> host_platform_include_root dictionaries account for arm64.

Hi Joe, thanks for clarifying!

In that case, I will accept a patch that rewrites the architecture for
OSX from arm64 to aarch64. Please don't extend the dict though, as it
will be duplicate information and thus harder to maintain. Something
along the lines:

arch = `uname -m`
# two sentence explanation (an extract from your email would suffice)
if macos and arch == "arm64"
    arch = "aarch64"

... keep going with the `arch` variable.

See https://sr.ht/~motiejus/bazel-zig-cc/#questions-amp-contributions
for how to send the patch. Thanks for your report!

Motiejus