Implement support for macOS Apple Silicon => x86_64 cross compilation

[fhanau]

I hope to use this in CI in the near future to compile x86 release binaries on Apple Silicon to make this process faster and have access to the latest compiler version. That can be discussed in detail on another issue.

[fhanau]

• The PR currently adds a test job that cross-compiles to x86 on the arm64-based and then runs the tests via Rosetta. This is solely to demonstrate that this change works, remove it before merging.

For macOS-based reviewers who want to try this out locally, bazel test --config=macos-cross-x86_64 //src/workerd/util:sqlite-test && file bazel-bin/src/workerd/util/sqlite-test is a good way to compile a test binary and confirm that it is compiled for x86, without having to recompile everything.

[danlapid]

Love it!
Any chance you want to take the same opportunity to add a build step to release.yml so we can remove the internal runner for macos arm64?

[npaun]

Cool

[fhanau]

Love it! Any chance you want to take the same opportunity to add a build step to release.yml so we can remove the internal runner for macos arm64?

That is something I have in mind (#2884 was a step in that direction), but it merits some discussion internally first – based on https://docs.github.com/en/actions/administering-github-actions/usage-limits-billing-and-administration#usage-limits we are limited to 5 concurrent macOS build jobs across the cloudflare org. We have encountered macOS runner exhaustion for workerd before. Adding a second release job on GitHub will not add much overhead (Apple Silicon macOS is the fastest free tier runner) but might be enough to make us hit runner exhaustion again occasionally and have macOS builds stall.

[danlapid]

As you’ve mentioned, I don’t think that the release build runs often enough. I think we should go ahead with it.
As Steve mentioned in an internal conversation, GitHub limits are something he’s working on, I don’t think we should work too hard to engineer around them.

[fhanau]

As you’ve mentioned, I don’t think that the release build runs often enough. I think we should go ahead with it. As Steve mentioned in an internal conversation, GitHub limits are something he’s working on, I don’t think we should work too hard to engineer around them.

👍 Let's discuss at the team meeting