Support macOS Big Sur and Apple Silicon hardware platform #11628

philwo · 2020-06-23T16:37:24Z

This is a tracking bug for adding support for macOS Big Sur and the Apple Silicon platform to Bazel. I'm currently trying to acquire a DTK to run some initial tests and will follow up here when I find out more.

We aim to have full support in time for their final release.

keith · 2020-06-23T17:32:02Z

This may be out of the scope of this discussion, but I think it would be nice to break the assumptions in bazel that if you're compiling for an Apple CPU you have to be running on darwin_x86_64 (previously, and now darwin*). This would unlock cross-compilation to Apple platforms from Linux and I think could be done without degrading the UX for macOS users. This would also likely make it easier to add more CPUs like this one.

keith · 2020-06-24T15:47:30Z

I also have a DTK coming and would be happy to contribute some here as this is a pre-req for us long term as well.

kayasoze · 2020-08-14T15:06:32Z

My DTK has arrived and I've hit this roadblock. Happy to help.

dmaclach · 2020-08-14T17:34:05Z

Just to be clear to what roadblock are you referring?

philwo · 2020-08-21T13:45:24Z

Just FYI, we're still waiting for the DTK, so no news from my side yet.

dmaclach · 2020-08-25T15:50:51Z

FYI

b235517#diff-1f4964536f397e8679625954c7139bd6

and

e4e06c0#diff-1f4964536f397e8679625954c7139bd6

add support for darwin_arm64 and darwin_arm64e respectively.

blaze build --config=darwin_arm64 should get you a basic Apple Silicon binary.

dmaclach · 2020-09-01T21:25:42Z

I think that #12035 should unblock folks. Apologies on my earlier assertions as I was using a different crosstool and forgot that my changes there were not available externally. We will leave this bug open for the time being until we have bazel working natively on Apple Silicon, but for the time being you should be able to build on x86_64 for arm64(e) and build (running an emulated bazel) on arm64 for arm64(e).

This adds support for darwin_arm64(e) to the crosstool. `bazel build examples/cpp:hello-world --cpu=darwin_arm64 --xcode_version=12` should function on both a intel and arm64 mac. Note that bazel still runs in emulation on arm64 mac until we have an arm64 darwin jdk. Fix for #11628 Closes #12035. PiperOrigin-RevId: 329582842

keith · 2020-11-06T16:24:34Z

Related bazelbuild/rules_apple#980

Any general update on this from google folks? Is anyone actively looking at this? I could probably spend some time on this soon, I have a DTK

BalestraPatrick · 2020-11-15T20:52:42Z

We are also blocked on being able to target arm64 and the iOS simulator. I also have a DTK but I'm unfamiliar with Bazel core, but happy to help in any way I can.

keith · 2020-11-15T20:54:26Z

AFAIUI currently we're blocked on the JDK not supporting Apple Silicon. Realistically after that I imagine the fact that homebrew doesn't support it either will make it difficult to build and test this.

BalestraPatrick · 2020-11-15T21:02:37Z

@keith Isn't the fact that Bazel doesn't support Apple Silicon a different problem? With my understanding, I assumed we should be able to still pass the right arguments to the compiler and build targeting arm64 and the iOS simulator even if Bazel isn't yet optimized with Apple Silicon.

keith · 2020-11-15T21:06:40Z

Sorry I thought you were hoping to do the build on the DTK as well. Yes we should be able to target the apple silicon simulator from x86_64 bazel runs. I don't think this will be an easy change based on a discussion at bazelcon (not sure if you were in the apple BoF). I think the problem is there isn't a way to differentiate simulator or device for the same architecture.

BalestraPatrick · 2020-11-15T22:06:07Z

Yeah, I was in the discussion so I'd love to know how big of a change this would be from some Google folks, since it could block Bazel adoption relatively soon for teams who want/need to support this new architecture.

keith · 2020-11-16T17:50:11Z

Looks like there's a zulu release for Apple Silicon https://www.azul.com/downloads/zulu-community/?os=macos&architecture=arm-64-bit&package=jdk

keith · 2020-11-19T02:58:21Z

@philwo given the blocker around simulator vs device builds, do googlers have an opinion on the solution? I'm interested in working on this but want to submit something that you all will be happy with as well.

philwo · 2020-11-19T07:03:28Z

@keith I think we'd be more than happy to take your design proposal / contribution on this 😊, but let's check whether there are any conflicts or opinions here - @dmaclach @susinmotion any concerns or opinions on this from your side?

The relevant context is how bazelbuild/rules_apple#980 should be dealt with, if I understand correctly.

philwo · 2020-11-19T07:05:06Z

@keith FYI, @meteorcloudy and me are looking into getting Bazel to build with the Apple Silicon native JDK. Thanks for pointing out that Azul has a Zulu release for this!

keith · 2020-11-19T12:48:12Z

Happy to hear you're working on the build! Once it's ready I'm definitely interested in trying it!

susinmotion · 2020-11-19T15:10:21Z

Yes, please, that would be amazing! I think this is related to some work that @gregestren 's team is doing; looping him in.

gregestren · 2020-11-19T15:45:19Z

@katre is there a relation to platforms or execution environments here?

katre · 2020-11-19T15:49:00Z

@gregestren There shouldn't be any need for changes to Bazel's platforms or toolchains machinery to support this. I'm happy to consult on using those facilities if needed.

philwo · 2020-11-19T19:49:12Z

Pasting some notes here, so I don't forget:

If we just run Bazel with the Apple Silicon Zulu, loading the JNI libraries will not work, because they're x86_64.

So we have to use an x86_64 Bazel (with x86_64 Zulu) and cross-compile Bazel first, which "should" work via:

bazel build --cpu=darwin_arm64 --host_cpu=darwin_arm64 //src:bazel

However, @meteorcloudy pointed out that this could lead Bazel to selecting the wrong sources for the mac build (as we use "darwin" only in the select statements). So we'll need something like this, but for Bazel: meteorcloudy@3139666

Regarding arm64 vs. arm64e, the latter one is more modern, but it appears that Zulu is built for arm64 - which is good (for now), because that doesn't require us to codesign every binary. Apparently that's only required for the newer arm64e binaries. If we do want to go to arm64e eventually, we'll have to codesign -v -s - --force my_lib.dylib/my_binary everything we build somehow.

keith · 2020-11-19T22:14:55Z

I wonder if we should replace the darwin conditional with one that means any of the darwin architectures as opposed to splitting out all cases? for example https://github.com/envoyproxy/envoy/pull/6182/files

jwbee · 2020-12-31T17:47:13Z

Please let me know what I am missing.

I see the same behavior as @ayankumarh which suggests that those of you who have this working have something else in your repo that isn't available to the rest of us. I can't get it working with any combination of the patches mentioned here.

jesec · 2021-01-15T15:42:14Z

It is surprisingly easy. I successfully built the latest commit (bbeb1da) on my M1 Mac mini.

Download bazelisk from https://github.com/bazelbuild/bazelisk/releases. darwin-amd64 is fine. Install it to /usr/local/bin/bazelisk.
Download and install JDK 11 (.dmg) from https://www.azul.com/downloads/zulu-community/?os=macos&architecture=arm-64-bit&package=jdk.
Clone Bazel repo: git clone git@github.com:bazelbuild/bazel.git --depth=1 --single-branch
Inside the repo, USE_BAZEL_VERSION=last_green bazelisk build -c opt --apple_platform_type=macos --cpu=darwin_arm64 //src:bazel

That's it.

Target //src:bazel up-to-date:
  bazel-bin/src/bazel
INFO: Elapsed time: 780.524s, Critical Path: 183.13s
INFO: 2985 processes: 179 internal, 2093 darwin-sandbox, 1 local, 712 worker.
INFO: Build completed successfully, 2985 total actions

https://drive.google.com/file/d/13b5_sd4d8LrZS18aVq8K2EOuxtPNmuWL/view?usp=sharing

jesec · 2021-01-15T16:08:16Z

#11628 (comment)

I spoke too soon 😢 Although it's an arm binary, host tools were built for x86_64 so Bazel still invokes everything under Rosetta.

Um.. This happens as well.

This change allows rules_foreign_cc to work on architectures other than x86_64. Bug: bazelbuild/bazel#11628 Test: manual. no longer fails with "ln: illegal option -- t" on darwin_arm64

Many downstream projects are still depending on the default cpu value being "darwin" instead of "darwin_x86_64" https://buildkite.com/bazel/bazel-auto-sheriff-face-with-cowboy-hat/builds/412 Related: bazelbuild#11628

Many downstream projects are still depending on the default cpu value on x86 macOS being "darwin" instead of "darwin_x86_64" https://buildkite.com/bazel/bazel-auto-sheriff-face-with-cowboy-hat/builds/412 Related: #11628 Closes #12918. PiperOrigin-RevId: 354279409

Related: #11628 Closes #12919. PiperOrigin-RevId: 354281564

chandlerc · 2021-03-31T04:18:54Z

Should this be closed given that there hasn't been a release yet with this support?

After this PR, we can use a x86 version of Bazel to build an ARM64 Bazel binary for Apple Silicon by ``` bazel build --cpu=darwin_arm64 //src:bazel ``` The Bazel client, embedded tools and embedded JDK are all native ARM64 binaries. Changes in this PR: 1. Add OpenJDK definitions for ARM64 macOS 2. Manually created the embedded JDK binaries on an Apple Silicon machine and uploaded them to the bazel mirror site. 3. AutoCpuConverter.java: identify the cpu value correctly 4. cc_toolchain_config.bzl: Explicitly specify the target platform also in the x86 cc toolchain, so that we can also do cross-platform compile from ARM64 to x86. With the native arm64 Bazel binary, building Bazel itself takes only half of the time compared with the x86 Bazel binary on an Apple DTK machine: ``` $ bazel build --cpu=darwin_arm64 --disk_cache= --repository_cache= //src:bazel Starting local Bazel server and connecting to it... ... Target //src:bazel up-to-date: bazel-bin/src/bazel INFO: Elapsed time: 1044.462s, Critical Path: 180.08s INFO: 2984 processes: 179 internal, 2092 darwin-sandbox, 1 local, 712 worker. INFO: Build completed successfully, 2984 total actions cp ./bazel-bin/src/bazel ~/bin/bazel-arm64 $ bazel-arm64 clean --expunge $ bazel-arm64 build --disk_cache= --repository_cache= //src:bazel Starting local Bazel server and connecting to it... ... Target //src:bazel up-to-date: bazel-bin/src/bazel INFO: Elapsed time: 464.470s, Critical Path: 114.88s INFO: 2984 processes: 179 internal, 2092 darwin-sandbox, 1 local, 712 worker. INFO: Build completed successfully, 2984 total actions ``` Closes: #11628 Closes #12900. PiperOrigin-RevId: 354058336

Many downstream projects are still depending on the default cpu value on x86 macOS being "darwin" instead of "darwin_x86_64" https://buildkite.com/bazel/bazel-auto-sheriff-face-with-cowboy-hat/builds/412 Related: #11628 Closes #12918. PiperOrigin-RevId: 354279409

After this PR, we can use a x86 version of Bazel to build an ARM64 Bazel binary for Apple Silicon by ``` bazel build --cpu=darwin_arm64 //src:bazel ``` The Bazel client, embedded tools and embedded JDK are all native ARM64 binaries. Changes in this PR: 1. Add OpenJDK definitions for ARM64 macOS 2. Manually created the embedded JDK binaries on an Apple Silicon machine and uploaded them to the bazel mirror site. 3. AutoCpuConverter.java: identify the cpu value correctly 4. cc_toolchain_config.bzl: Explicitly specify the target platform also in the x86 cc toolchain, so that we can also do cross-platform compile from ARM64 to x86. With the native arm64 Bazel binary, building Bazel itself takes only half of the time compared with the x86 Bazel binary on an Apple DTK machine: ``` $ bazel build --cpu=darwin_arm64 --disk_cache= --repository_cache= //src:bazel Starting local Bazel server and connecting to it... ... Target //src:bazel up-to-date: bazel-bin/src/bazel INFO: Elapsed time: 1044.462s, Critical Path: 180.08s INFO: 2984 processes: 179 internal, 2092 darwin-sandbox, 1 local, 712 worker. INFO: Build completed successfully, 2984 total actions cp ./bazel-bin/src/bazel ~/bin/bazel-arm64 $ bazel-arm64 clean --expunge $ bazel-arm64 build --disk_cache= --repository_cache= //src:bazel Starting local Bazel server and connecting to it... ... Target //src:bazel up-to-date: bazel-bin/src/bazel INFO: Elapsed time: 464.470s, Critical Path: 114.88s INFO: 2984 processes: 179 internal, 2092 darwin-sandbox, 1 local, 712 worker. INFO: Build completed successfully, 2984 total actions ``` Closes: #11628 Closes #12900. PiperOrigin-RevId: 354058336 Revert default cpu value on x86 macOS to "darwin" Many downstream projects are still depending on the default cpu value on x86 macOS being "darwin" instead of "darwin_x86_64" https://buildkite.com/bazel/bazel-auto-sheriff-face-with-cowboy-hat/builds/412 Related: #11628 Closes #12918. PiperOrigin-RevId: 354279409

After this PR, we can use a x86 version of Bazel to build an ARM64 Bazel binary for Apple Silicon by ``` bazel build --cpu=darwin_arm64 //src:bazel ``` The Bazel client, embedded tools and embedded JDK are all native ARM64 binaries. Changes in this PR: 1. Add OpenJDK definitions for ARM64 macOS 2. Manually created the embedded JDK binaries on an Apple Silicon machine and uploaded them to the bazel mirror site. 3. AutoCpuConverter.java: identify the cpu value correctly 4. cc_toolchain_config.bzl: Explicitly specify the target platform also in the x86 cc toolchain, so that we can also do cross-platform compile from ARM64 to x86. With the native arm64 Bazel binary, building Bazel itself takes only half of the time compared with the x86 Bazel binary on an Apple DTK machine: ``` $ bazel build --cpu=darwin_arm64 --disk_cache= --repository_cache= //src:bazel Starting local Bazel server and connecting to it... ... Target //src:bazel up-to-date: bazel-bin/src/bazel INFO: Elapsed time: 1044.462s, Critical Path: 180.08s INFO: 2984 processes: 179 internal, 2092 darwin-sandbox, 1 local, 712 worker. INFO: Build completed successfully, 2984 total actions cp ./bazel-bin/src/bazel ~/bin/bazel-arm64 $ bazel-arm64 clean --expunge $ bazel-arm64 build --disk_cache= --repository_cache= //src:bazel Starting local Bazel server and connecting to it... ... Target //src:bazel up-to-date: bazel-bin/src/bazel INFO: Elapsed time: 464.470s, Critical Path: 114.88s INFO: 2984 processes: 179 internal, 2092 darwin-sandbox, 1 local, 712 worker. INFO: Build completed successfully, 2984 total actions ``` Closes: #11628 Closes #12900. PiperOrigin-RevId: 354058336 Revert default cpu value on x86 macOS to "darwin" Many downstream projects are still depending on the default cpu value on x86 macOS being "darwin" instead of "darwin_x86_64" https://buildkite.com/bazel/bazel-auto-sheriff-face-with-cowboy-hat/builds/412 Related: #11628 Closes #12918. PiperOrigin-RevId: 354279409 Update platform version to 0.0.4 Use configuration flags for //src/conditions:darwin_arm64 Partially reverts 6d637f4, to allow cross-compiling Bazel from darwin_x86_64 to darwin_arm64 with the `--cpu=darwin_arm64` flag. The only source that is different between darwin_x86_64 and darwin_arm64 now is the embedded JDK. Closes #12653. PiperOrigin-RevId: 346298051 Make sure Bazel selects correct remote JDK on Apple Silicon

Darko-Huma · 2021-07-13T12:53:27Z

 bazel run gazelle                                                                              
(14:52:48) INFO: Current date is 2021-07-13
(14:52:48) ERROR: While resolving toolchains for target //:gazelle-runner: no matching toolchains found for types @io_bazel_rules_go//go:toolchain
(14:52:48) ERROR: Analysis of target '//:gazelle' failed; build aborted: no matching toolchains found for types @io_bazel_rules_go//go:toolchain
(14:52:48) INFO: Elapsed time: 0.082s
(14:52:48) INFO: 0 processes.
(14:52:48) ERROR: Build failed. Not running target

Bazel version
4.1
Apple Silicon M1

katre · 2021-07-13T14:10:23Z

@Darko-Huma: This is an issue with rules_go, you'll need to report it there.

bazelbuild/bazel#11628 is in Release 4.1 - May 2021 #13099 Pin vs rm for build repeatability.

philwo added type: feature request P2 We'll consider working on this in future. (Assignee optional) team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website labels Jun 23, 2020

philwo self-assigned this Jun 23, 2020

dmaclach mentioned this issue Sep 1, 2020

Add support to crosstool for darwin_arm64(e) #12035

Closed

keith mentioned this issue Nov 6, 2020

Missing support for iPhoneSimulator platform on arm64 bazelbuild/rules_apple#980

Closed

jesec mentioned this issue Jan 16, 2021

toolchain_mappings: remove unnecessary arch constraints bazel-contrib/rules_foreign_cc#456

Merged

This was referenced Jan 19, 2021

Mac M1 Tensorflow Set Up google-ai-edge/mediapipe#1514

Closed

Command succeeded, but not all targets were analyzed, MAC M1. google-ai-edge/mediapipe#1516

Closed

jayconrod mentioned this issue Jan 25, 2021

Support Apple Silicon bazel-contrib/rules_go#2795

Closed

meteorcloudy mentioned this issue Jan 26, 2021

Add native support for Apple Silicon #12900

Closed

bazel-io closed this as completed in 8c7e11a Jan 27, 2021

This was referenced Jan 28, 2021

Revert default cpu value on x86 macOS to "darwin" #12918

Closed

Avoid downloading x86_64 remote JDK on Apple Silicon #12919

Closed

bazel-io pushed a commit that referenced this issue Jan 28, 2021

Avoid downloading x86_64 remote JDK on Apple Silicon

ecddf60

Related: #11628 Closes #12919. PiperOrigin-RevId: 354281564

meteorcloudy mentioned this issue Mar 19, 2021

Release 4.1 - May 2021 #13099

Closed

9 tasks

poetaman mentioned this issue May 25, 2021

Issue building on MacOS chipsalliance/verible#260

Closed

acecilia mentioned this issue Jun 8, 2021

GoogleSignIn SDK on Apple Silicon (M1) firebase/firebase-ios-sdk#7208

Closed

jonmeow mentioned this issue Aug 4, 2021

Pin bazeliskrc to 4.1.0 which supports m1 carbon-language/carbon-lang#705

Merged

jonmeow added a commit to carbon-language/carbon-lang that referenced this issue Aug 5, 2021

Pin bazeliskrc to 4.1.0 which supports m1 (#705)

ccdf0a6

bazelbuild/bazel#11628 is in Release 4.1 - May 2021 #13099 Pin vs rm for build repeatability.

vidheyoza mentioned this issue Aug 30, 2021

Building Bazel inside Ubuntu docker on M1 Mac #13925

Closed

justin-f-perez mentioned this issue Nov 19, 2021

macOS arm64 (lack of) support should be documented google-ai-edge/mediapipe#2798

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support macOS Big Sur and Apple Silicon hardware platform #11628

Support macOS Big Sur and Apple Silicon hardware platform #11628

philwo commented Jun 23, 2020

keith commented Jun 23, 2020

keith commented Jun 24, 2020

kayasoze commented Aug 14, 2020

dmaclach commented Aug 14, 2020

philwo commented Aug 21, 2020

dmaclach commented Aug 25, 2020

dmaclach commented Sep 1, 2020

keith commented Nov 6, 2020

BalestraPatrick commented Nov 15, 2020

keith commented Nov 15, 2020

BalestraPatrick commented Nov 15, 2020

keith commented Nov 15, 2020

BalestraPatrick commented Nov 15, 2020

keith commented Nov 16, 2020

keith commented Nov 19, 2020

philwo commented Nov 19, 2020

philwo commented Nov 19, 2020

keith commented Nov 19, 2020

susinmotion commented Nov 19, 2020

gregestren commented Nov 19, 2020

katre commented Nov 19, 2020

philwo commented Nov 19, 2020

keith commented Nov 19, 2020

jwbee commented Dec 31, 2020

jesec commented Jan 15, 2021

jesec commented Jan 15, 2021 •

edited

Loading

chandlerc commented Mar 31, 2021

Darko-Huma commented Jul 13, 2021

katre commented Jul 13, 2021

Support macOS Big Sur and Apple Silicon hardware platform #11628

Support macOS Big Sur and Apple Silicon hardware platform #11628

Comments

philwo commented Jun 23, 2020

keith commented Jun 23, 2020

keith commented Jun 24, 2020

kayasoze commented Aug 14, 2020

dmaclach commented Aug 14, 2020

philwo commented Aug 21, 2020

dmaclach commented Aug 25, 2020

dmaclach commented Sep 1, 2020

keith commented Nov 6, 2020

BalestraPatrick commented Nov 15, 2020

keith commented Nov 15, 2020

BalestraPatrick commented Nov 15, 2020

keith commented Nov 15, 2020

BalestraPatrick commented Nov 15, 2020

keith commented Nov 16, 2020

keith commented Nov 19, 2020

philwo commented Nov 19, 2020

philwo commented Nov 19, 2020

keith commented Nov 19, 2020

susinmotion commented Nov 19, 2020

gregestren commented Nov 19, 2020

katre commented Nov 19, 2020

philwo commented Nov 19, 2020

keith commented Nov 19, 2020

jwbee commented Dec 31, 2020

jesec commented Jan 15, 2021

jesec commented Jan 15, 2021 • edited Loading

chandlerc commented Mar 31, 2021

Darko-Huma commented Jul 13, 2021

katre commented Jul 13, 2021

jesec commented Jan 15, 2021 •

edited

Loading