mirror of https://gitlab.com/pulsechaincom/prysm-pulse.git synced 2024-12-23 11:57:18 +00:00

Add cross compilation for OSX ARM64 (Apple Silicon) (#10981 )

* Upgrade Grail Bazel toolchain to latest release v0.7.2

This should allow Prysm to compile on Ubuntu 21.10 and 22.04

* Changes necessary in .bazelrc for new version of com_grail_bazel_toolchain

* Add cross compilation for OSX ARM64 (Apple Silicon)

* Update cross-toolchain README to include osx_arm64

* Add double quotes to shell code

* Rename install_clang_cross10.sh -> install_clang_cross.sh

* Update with prysmatic labs uploaded assets

* Touch README to trigger CI

* Revert "Touch README to trigger CI"

This reverts commit 826ac8a6d8da4fe0bd8503511b00576e50861850.

Co-authored-by: Raul Jordan <raul@prysmaticlabs.com>
Co-authored-by: prestonvanloon <preston@prysmaticlabs.com>

2022-08-11 21:40:24 +00:00

3.4 KiB

Raw Blame History

Multiarch Cross Compiling Toolchain

Toolchain suite

This package declares a c++ toolchain suite with cross compilers for targeting five platforms:

linux_amd64
linux_arm64
osx_amd64
osx_arm64
windows_amd64

This toolchain suite describes cross compile configuration with a Dockerfile with the appropriate host dependencies. These toolchains can be used locally (see caveats), Remote Build Execution (RBE), and in a docker sandbox (like RBE, but local).

Cross compile target support

target	linux_amd64	linux_arm64	osx_amd64	osx_arm64	windows_amd64
`//beacon-chain`	✔️ docker-sandbox and RBE, supported locally only	✔️ docker-sandbox and RBE	✔️ docker-sandbox	✔️ docker-sandbox	✔️ docker-sandbox
`//validator`	✔️ docker-sandbox and RBE	✔️ docker-sandbox and RBE	✔️ docker-sandbox	✔️ docker-sandbox	✔️

The configurations above are enforced via pull request presubmit checks.

Bazel config flag values

Use these values with --config=<flag>, multiple times if more than one value is defined in the table. Example: bazel build //beacon-chain --config=windows_amd64_docker to build windows binary in a docker sandbox.

Config	linux_amd64	linux_arm64	osx_amd64	osx_arm64	windows_amd64
Local run	`linux_amd64`	`linux_arm64`	`osx_amd64`	`osx_arm64`	`windows_amd64`
Docker sandbox	`linux_amd64_docker`	`linux_arm64_docker`	`osx_amd64_docker`	`osx_arm64_docker`	`windows_amd64_docker`
RBE (See Caveats)	`linux_amd64` and `remote`	`linux_arm64` and `remote`	`osx_amd64` and `remote`	`osx_arm64` and `remote`	`windows_amd64` and `remote`

Caveats

There are a few caveats to each of these strategies.

Local runs require clang compiler and the appropriate cross compilers installed. These runs should only be considered for a power user or user with specific build requirements. See the Dockerfile setup scripts to understand what dependencies must be installed and where.
Docker sandbox is slow. Like really slow! The purpose of the docker sandbox is to test RBE builds without deploying a full RBE system. Each build action is executed in its own container. Given the large number of small targets in this project, the overhead of creating docker containers makes this strategy the slowest of all, but requires zero additional setup.
Remote Build Execution is by far the fastest, if you have a RBE backend available. This is another advanced use case which will require two config flags above as well as additional flags to specify the --remote_executor. Some of these flags are present in the project .bazelrc with example values, but commented out.

3.4 KiB Raw Blame History