cfallin opened issue #7469:
On my M1 machine, with Rust 1.73.0, having removed
target/
and starting from a freshmain
(630f8e32d8921a08ead7d27955686342f9f6fa06
), I see:cfallin@min:~/work/wasmtime% cargo test [ ...] Compiling object v0.32.0 Compiling wasi v0.11.0+wasi-snapshot-preview1 Compiling serde_derive v1.0.188 Compiling wasi-preview1-component-adapter v15.0.0 (/Users/cfallin/work/wasmtime/crates/wasi-preview1-component-adapter) error: failed to run custom build command for `wasi-preview1-component-adapter v15.0.0 (/Users/cfallin/work/wasmtime/crates/wasi-preview1-component-adapter)` Caused by: process didn't exit successfully: `/Users/cfallin/work/wasmtime/target/debug/build/test-programs-artifacts-02bef33e1d1021a1/out/release/build/wasi-preview1-component-adapter-ced036fa4eed0f20/build-script-build` (signal: 9, SIGKILL: kill) warning: build failed, waiting for other jobs to finish... thread 'main' panicked at crates/test-programs/artifacts/build.rs:122:5: assertion failed: status.success() note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
and if I try launching
build-script-build
manually, I seecfallin@min:~/work/wasmtime% /Users/cfallin/work/wasmtime/target/debug/build/test-programs-artifacts-02bef33e1d1021a1/out/release/build/wasi-preview1-component-adapter-ced036fa4eed0f20/build-script-build zsh: killed
A little more digging indicates
cfallin@min:~/work/wasmtime% codesign -v /Users/cfallin/work/wasmtime/target/debug/build/test-programs-artifacts-02bef33e1d1021a1/out/release/build/wasi-preview1-component-adapter-ced036fa4eed0f20/build-script-build /Users/cfallin/work/wasmtime/target/debug/build/test-programs-artifacts-02bef33e1d1021a1/out/release/build/wasi-preview1-component-adapter-ced036fa4eed0f20/build-script-build: code object is not signed at all In architecture: arm64
which is wildly confusing, because macOS/aarch64 requires all binaries to be signed (even just locally), and the way that dev-tools normally handle this is by invoking
codesign
after linking to add an ad-hoc local signature. Lack of any signature would explainSIGKILL
from the kernel.I'm also fairly perplexed because I believe I'm not the only one here using macOS/aarch64 (cc @alexcrichton at the very least?). The one slightly non-mainstream-path thing I'm doing is using Nix/home-manager locally (
rustup
andcargo
are both~/.nix-profile/bin/cargo
) but local Rust development works perfectly fine otherwise.I'm not sure what to debug from here -- but is there some custom build invocation somewhere that is doing something manually and not signing the binary?
cfallin edited issue #7469:
On my M1 machine, with Rust 1.73.0, having removed
target/
and starting from a freshmain
(630f8e32d8921a08ead7d27955686342f9f6fa06
), I see:cfallin@min:~/work/wasmtime% cargo test [ ...] Compiling object v0.32.0 Compiling wasi v0.11.0+wasi-snapshot-preview1 Compiling serde_derive v1.0.188 Compiling wasi-preview1-component-adapter v15.0.0 (/Users/cfallin/work/wasmtime/crates/wasi-preview1-component-adapter) error: failed to run custom build command for `wasi-preview1-component-adapter v15.0.0 (/Users/cfallin/work/wasmtime/crates/wasi-preview1-component-adapter)` Caused by: process didn't exit successfully: `/Users/cfallin/work/wasmtime/target/debug/build/test-programs-artifacts-02bef33e1d1021a1/out/release/build/wasi-preview1-component-adapter-ced036fa4eed0f20/build-script-build` (signal: 9, SIGKILL: kill) warning: build failed, waiting for other jobs to finish... thread 'main' panicked at crates/test-programs/artifacts/build.rs:122:5: assertion failed: status.success() note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
and if I try launching
build-script-build
manually, I seecfallin@min:~/work/wasmtime% /Users/cfallin/work/wasmtime/target/debug/build/test-programs-artifacts-02bef33e1d1021a1/out/release/build/wasi-preview1-component-adapter-ced036fa4eed0f20/build-script-build zsh: killed
A little more digging indicates
cfallin@min:~/work/wasmtime% codesign -v /Users/cfallin/work/wasmtime/target/debug/build/test-programs-artifacts-02bef33e1d1021a1/out/release/build/wasi-preview1-component-adapter-ced036fa4eed0f20/build-script-build /Users/cfallin/work/wasmtime/target/debug/build/test-programs-artifacts-02bef33e1d1021a1/out/release/build/wasi-preview1-component-adapter-ced036fa4eed0f20/build-script-build: code object is not signed at all In architecture: arm64
which is wildly confusing, because macOS/aarch64 requires all binaries to be signed (even just locally), and the way that dev-tools normally handle this is by invoking
codesign
after linking to add an ad-hoc local signature. Lack of any signature would explainSIGKILL
from the kernel.I'm also fairly perplexed because I believe I'm not the only one here using macOS/aarch64 (cc @alexcrichton at the very least?). The one slightly non-mainstream-path thing I'm doing is using Nix/home-manager locally (
rustup
andcargo
are~/.nix-profile/bin/{rustup,cargo}
) but local Rust development works perfectly fine otherwise.I'm not sure what to debug from here -- but is there some custom build invocation somewhere that is doing something manually and not signing the binary?
alexcrichton commented on issue #7469:
What macOS version are you on? I haven't had any issues myself but I also haven't updated to the latest (sonoma I think?), I'm on 13.5.1.
I'm not aware of anything codesigning related that rustc does myself, so if this is a new requirement of sonoma then that may be what's happening. Otherwise does this reproduce in a "hello world" for example with
cargo run
? (e.g. can any rustc-generated executable run on your system?)
cfallin commented on issue #7469:
I'm on Ventura (13.6) -- haven't updated to Sonoma yet.
Codesigning has actually been a platform requirement on macOS/aarch64 since Apple Silicon rolled out; it's handled mostly transparently in either the linker or compiler drivers (I'm not sure which) by adding an ad-hoc signature to any binary one compiles locally. That's part of why I'm so surprised this is coming up!
I can build and run a Hello World fine; I've been building
cilf-util
andwasmtime
(CLI binary) and developing with both for the past few weeks with no problem; it's just now that I thought to do acargo test
locally in the root and discovered this.I can reproduce both on personal (M1) and work (M2) laptops; I'll try to bisect further...
alexcrichton commented on issue #7469:
Weird! I dunno if something changed in 13.6, but I at least have been running tests regularly on an M2 for months now with no hiccups. I'd be pretty surprised if Nix factored meaningfully into this, so I'm as confused as you are...
cfallin commented on issue #7469:
I've bisected this to f4be360648e080aae8d856967e6d2c40cccf57da (#7182), in a clean checkout and removing
target
each time to avoid incremental compilation weirdness. I guess that's the PR I would have suspected as well. Trying to dig into the actual failure now...
cfallin closed issue #7469:
On my M1 machine, with Rust 1.73.0, having removed
target/
and starting from a freshmain
(630f8e32d8921a08ead7d27955686342f9f6fa06
), I see:cfallin@min:~/work/wasmtime% cargo test [ ...] Compiling object v0.32.0 Compiling wasi v0.11.0+wasi-snapshot-preview1 Compiling serde_derive v1.0.188 Compiling wasi-preview1-component-adapter v15.0.0 (/Users/cfallin/work/wasmtime/crates/wasi-preview1-component-adapter) error: failed to run custom build command for `wasi-preview1-component-adapter v15.0.0 (/Users/cfallin/work/wasmtime/crates/wasi-preview1-component-adapter)` Caused by: process didn't exit successfully: `/Users/cfallin/work/wasmtime/target/debug/build/test-programs-artifacts-02bef33e1d1021a1/out/release/build/wasi-preview1-component-adapter-ced036fa4eed0f20/build-script-build` (signal: 9, SIGKILL: kill) warning: build failed, waiting for other jobs to finish... thread 'main' panicked at crates/test-programs/artifacts/build.rs:122:5: assertion failed: status.success() note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
and if I try launching
build-script-build
manually, I seecfallin@min:~/work/wasmtime% /Users/cfallin/work/wasmtime/target/debug/build/test-programs-artifacts-02bef33e1d1021a1/out/release/build/wasi-preview1-component-adapter-ced036fa4eed0f20/build-script-build zsh: killed
A little more digging indicates
cfallin@min:~/work/wasmtime% codesign -v /Users/cfallin/work/wasmtime/target/debug/build/test-programs-artifacts-02bef33e1d1021a1/out/release/build/wasi-preview1-component-adapter-ced036fa4eed0f20/build-script-build /Users/cfallin/work/wasmtime/target/debug/build/test-programs-artifacts-02bef33e1d1021a1/out/release/build/wasi-preview1-component-adapter-ced036fa4eed0f20/build-script-build: code object is not signed at all In architecture: arm64
which is wildly confusing, because macOS/aarch64 requires all binaries to be signed (even just locally), and the way that dev-tools normally handle this is by invoking
codesign
after linking to add an ad-hoc local signature. Lack of any signature would explainSIGKILL
from the kernel.I'm also fairly perplexed because I believe I'm not the only one here using macOS/aarch64 (cc @alexcrichton at the very least?). The one slightly non-mainstream-path thing I'm doing is using Nix/home-manager locally (
rustup
andcargo
are~/.nix-profile/bin/{rustup,cargo}
) but local Rust development works perfectly fine otherwise.I'm not sure what to debug from here -- but is there some custom build invocation somewhere that is doing something manually and not signing the binary?
cfallin commented on issue #7469:
I've worked it out: my home-manager setup was shadowing the system clang/LLVM with a Nix-provided clang/LLVM, and that one apparently knows how to create macOS/aarch64 binaries but does not sign them by default. (As one does?) And because home-manager is so neat and good at applying the same config everywhere, I had applied this to my work and personal laptops. Removing that shadowing and going back to system clang fixes the build. Sorry for the noise!
Last updated: Dec 23 2024 at 12:05 UTC