chore: fixing M3 devcontainer builds

[mrzeszutko]

Fix: ARM64 Mac (M3) Devcontainer Build Failures

Problem

Building inside a devcontainer on Mac with Apple M3 chip fails in multiple ways:

1. SIGILL crashes — The bb-sol build step crashes when running honk_solidity_key_gen, and E2E tests fail with Illegal instruction errors.
2. Rust compilation failures — The noir build fails with can't find crate for serde and similar errors when noir and avm-transpiler build in parallel, racing on the shared CARGO_HOME.

Root Cause

SVE instructions from zig -target native

1. CI runs on AWS Graviton (ARM64 with SVE vector extensions)
2. The zig compiler wrapper uses -target native-linux-gnu.2.35, which on Graviton enables SVE instructions
3. Mac M3 devcontainer (ARM64 without SVE) downloads the same cached binaries
4. Binaries contain SVE opcodes (e.g. 0x04be4000) that Apple Silicon can't execute → SIGILL

Cache keys already include architecture via cache_content_hash (which appends $OSTYPE-$(uname -m)), so amd64 vs arm64 caches never collide. The problem is specifically that two ARM64 machines (Graviton with SVE vs Apple Silicon without SVE) share the same architecture tag but have different CPU feature sets. The fix is to stop emitting CPU-specific instructions in the first place.

Parallel Rust build race condition

The top-level bootstrap runs noir and avm-transpiler builds in parallel. Both invoke cargo build, and both share the same CARGO_HOME (~/.cargo) which contains the crate registry and download cache. When both cargo processes run concurrently, they race on shared registry state, causing downstream crates (e.g. serde-big-array, ecdsa) to fail with can't find crate errors during compilation. This does not happen on CI where builds are cached, only on local fresh builds (e.g. NO_CACHE=1).

Fixes

1. Zig compiler wrappers: explicit ARM64 target

Files: barretenberg/cpp/scripts/zig-cc.sh, barretenberg/cpp/scripts/zig-c++.sh

Changed -target native-linux-gnu.2.35 to use explicit aarch64-linux-gnu.2.35 on ARM64 Linux. This produces generic ARM64 code without CPU-specific extensions (SVE, etc.), ensuring binaries work on all ARM64 machines — Graviton, Apple Silicon, Ampere, etc.

x86_64 behavior is unchanged (still uses native).

2. Extract native_cache_key variable in barretenberg bootstrap

File: barretenberg/cpp/bootstrap.sh

Extracted the repeated cache key pattern barretenberg-$native_preset-$hash into a single native_cache_key variable, used by build_native_objects, build_native, and related functions. Pure refactor, no change in cache key values.

3. Better error handling in init_honk.sh

File: barretenberg/sol/scripts/init_honk.sh

Added set -eu so the script fails immediately on error instead of silently continuing after SIGILL. Added an existence check for the honk_solidity_key_gen binary with a clear error message.

4. Serialize parallel cargo builds with flock

Files: noir/bootstrap.sh, avm-transpiler/bootstrap.sh

Both scripts wrap their cargo build invocations with flock -x 200 on a shared lock file (/tmp/rustup.lock):

(
  flock -x 200
  cd noir-repo && cargo build --locked --release --target-dir target
) 200>/tmp/rustup.lock

This acquires an exclusive file lock before running cargo, so if both noir and avm-transpiler builds run in parallel, one waits for the other to finish. The lock is automatically released when the subshell exits. This eliminates the CARGO_HOME race condition without requiring changes to the top-level parallelism.

Notes

E2E Tests

The E2E test failures (SIGKILL from invalid instructions) have the same root cause as the SIGILL crashes — the bb binary used by tests was from the SVE-contaminated cache. After rebuilding with these fixes, E2E tests work.

[ludamad]

This feels hacky. There must be a more targeted solution for your fix

[ludamad]

Is there no generic native target that is more conservative?

[ludamad]

I thought about it. I'm ok with this. but can we add -mcpu=apple_m1 and just more concisely say this is to make sure arm64 builds work on the lowest common denominator apple_m1 arm64 subset?

[ludamad]

some notes

[ludamad]

this would be nicer if if it was of the form 'flock cmd' but would need some care to set up. looks ok