cranelift build scripts embed absolute OUT_DIR paths in generated source, breaking reproducible builds

[travisdowns]

Summary

The build.rs scripts for cranelift-codegen and cranelift-assembler-x64 embed absolute filesystem paths into generated Rust source files. These paths change across different build environments (different machines, different --target-dir values, sandboxed build systems like Bazel or Nix), producing non-reproducible build artifacts.

Status

cranelift-codegen: Fixed on main by 0694bba ("Strip prefixes in file names"), which replaces OUT_DIR paths with <OUT_DIR> in the ISLE-generated source. Sorry for the noise on this one — I was testing against v32.0.0 and missed that this was already fixed. I'll pick this up when the next release ships.

cranelift-assembler-x64: Still unfixed on main. See details below.

cranelift-assembler-x64

cranelift/assembler-x64/build.rs writes absolute OUT_DIR paths directly into generated-files.rs with no attempt to relativize:

for file in &built_files {
    writeln!(vec_of_built_files, "  {:?}.into(),", file.display()).unwrap();
}

`built_files` contains absolute paths derived from `OUT_DIR`, so `generated-files.rs` ends up with:

vec![
  "/home/alice/wasmtime/target/debug/build/cranelift-assembler-x64-abc123/out/assembler.rs".into(),
]

Verified still present on main (d5f1b97).

Impact

• Standard Cargo builds: building on different machines, or with --target-dir outside the workspace, produces different generated source and different final binaries
• Sandboxed builds (Bazel, Nix, etc.): each build action runs in a unique sandbox directory, so every build produces a different binary even on the same machine with the same inputs

Reproducer

cd wasmtime

CARGO_TARGET_DIR=/tmp/build1 cargo build -p cranelift-assembler-x64
CARGO_TARGET_DIR=/tmp/build2 cargo build -p cranelift-assembler-x64

# Different absolute paths in generated-files.rs:
cat /tmp/build1/debug/build/cranelift-assembler-x64-*/out/generated-files.rs
# vec![
#   "/tmp/build1/debug/build/cranelift-assembler-x64-8eadefadaa0bb4cd/out/assembler.rs".into(),
# ]

cat /tmp/build2/debug/build/cranelift-assembler-x64-*/out/generated-files.rs
# vec![
#   "/tmp/build2/debug/build/cranelift-assembler-x64-8eadefadaa0bb4cd/out/assembler.rs".into(),
# ]

Environment

• Discovered building wasmtime 32.0.0 via Bazel (rules_rust) with sandboxed execution
• Also reproducible with standard Cargo using different --target-dir values

[cfallin]

@travisdowns thanks for the report -- we're happy to take PRs to fix reproducible build issues!

[travisdowns]

@travisdowns thanks for the report -- we're happy to take PRs to fix reproducible build issues!

I was in the middle of that, but just noticed on main there have been changes already in this which might fix it ... that escaped my attention. Will update shortly.

[travisdowns]

Updated the issue: cranelift-codegen was already fixed on main by 0694bba ("Strip prefixes in file names"). Only cranelift-assembler-x64 remains affected. Working on a PR for that now.

[travisdowns]

On closer look, generated-files.rs is only consumed by the cranelift-assembler-x64 utility binary (main.rs), not the library. For a utility that prints paths to generated code, absolute paths are the right behavior — relative or placeholder paths would make the output less useful.

It's possible to make the generated-files.rs source itself deterministic (e.g. by using env!("OUT_DIR") to defer path resolution to compile time), but the binary would still contain the absolute path after env!() expansion, so the non-determinism just moves from the source file to the compiled output. Not much of a win.

I think this issue can be closed — the cranelift-codegen side was already fixed by 0694bba, and the cranelift-assembler-x64 side doesn't need fixing.

Sorry for the noise!