wasmtime / issue #13121 cranelift build scripts embed abs... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #13121 cranelift build scripts embed abs...

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:26):

travisdowns opened issue #13121:

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.

Both issues are present on main as of d5f1b973e48b.

Affected crates

1. 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(),
]
This path changes with the build directory, user home directory, or sandbox instance.

2. cranelift-codegen

make_isle_source_path_relative() in cranelift/codegen/build.rs tries to strip cur_dir (the crate's source directory) from file paths:
fn make_isle_source_path_relative(
    cur_dir: &std::path::Path,
    filename: &std::path::Path,
) -> std::path::PathBuf {
    if let Ok(suffix) = filename.strip_prefix(&cur_dir) {
        suffix.to_path_buf()
    } else {
        filename.to_path_buf()  // ← falls back to absolute path
    }
}
This function is called with isle_dir (= OUT_DIR) as the filename. Since OUT_DIR is under the target/ directory and not under the crate source directory, strip_prefix fails, and the absolute path falls through unchanged. These absolute paths then get embedded into ISLE-generated source files (isle_x64.rs, etc.) as:

Error string literals: "no rule matched for term ... at /home/alice/wasmtime/target/debug/build/cranelift-codegen-XXX/out/assembler.isle line 18"

Source location comments: // Rule at /home/alice/.../assembler.isle line 19

The paths for source inputs (under crate_dir) ARE correctly relativized because crate_dir is the current working directory. Only paths under OUT_DIR leak through.

Impact

Standard Cargo builds: building on different machines, or with different --target-dir, 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

Tested on v32.0.0 (cranelift 0.119.0) and confirmed still present on main.
cd wasmtime

# Build with two different target directories
CARGO_TARGET_DIR=/tmp/build1 cargo build -p cranelift-codegen --features x86 -p cranelift-assembler-x64
CARGO_TARGET_DIR=/tmp/build2 cargo build -p cranelift-codegen --features x86 -p cranelift-assembler-x64

# cranelift-assembler-x64: 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(),
# ]

# cranelift-codegen: absolute paths in ISLE-generated source
# (despite make_isle_source_path_relative trying to strip them)
grep -c "/tmp/build1" /tmp/build1/debug/build/cranelift-codegen-*/out/isle_x64.rs
# → 297 matches — all from OUT_DIR paths where strip_prefix failed
Environment

Discovered building wasmtime 32.0.0 via Bazel (rules_rust) with sandboxed execution

Confirmed present on main (d5f1b973e48b)

Also reproducible with standard Cargo using different --target-dir values

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:27):

travisdowns edited issue #13121:

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.

Both issues are present on main as of d5f1b973e48b.

Affected crates

1. 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(),
]
This path changes with the build directory, user home directory, or sandbox instance.

2. cranelift-codegen

make_isle_source_path_relative() in cranelift/codegen/build.rs tries to strip cur_dir (the crate's source directory) from file paths:
fn make_isle_source_path_relative(
    cur_dir: &std::path::Path,
    filename: &std::path::Path,
) -> std::path::PathBuf {
    if let Ok(suffix) = filename.strip_prefix(&cur_dir) {
        suffix.to_path_buf()
    } else {
        filename.to_path_buf()  // ← falls back to absolute path
    }
}
This function is called with isle_dir (= OUT_DIR) as the filename. When OUT_DIR is a descendant of cur_dir, strip_prefix succeeds and paths are correctly relativized — this is the common case in standard Cargo builds where target/ is under the workspace root and the crate source is also under the workspace root. However, when OUT_DIR is NOT under cur_dir, strip_prefix fails and the absolute path falls through unchanged. This happens in:

Sandboxed builds (Bazel, Nix, etc.) where OUT_DIR and CWD are under different subtrees of the sandbox

Cargo builds with --target-dir pointing outside the workspace (e.g. CARGO_TARGET_DIR=/tmp/build)

Any build where the output directory tree doesn't share a prefix with the source directory

These absolute paths get embedded into ISLE-generated source files (isle_x64.rs, etc.) as:

Error string literals: "no rule matched for term ... at /home/alice/wasmtime/target/debug/build/cranelift-codegen-XXX/out/assembler.isle line 18"

Source location comments: // Rule at /home/alice/.../assembler.isle line 19

The paths for source inputs (under crate_dir) ARE correctly relativized because crate_dir is the current working directory. Only paths under OUT_DIR leak through when it's outside the CWD tree.

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

Tested on v32.0.0 (cranelift 0.119.0) and confirmed still present on main.
cd wasmtime

# Build with two different target directories (outside the workspace)
CARGO_TARGET_DIR=/tmp/build1 cargo build -p cranelift-codegen --features x86 -p cranelift-assembler-x64
CARGO_TARGET_DIR=/tmp/build2 cargo build -p cranelift-codegen --features x86 -p cranelift-assembler-x64

# cranelift-assembler-x64: 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(),
# ]

# cranelift-codegen: absolute paths in ISLE-generated source
# (make_isle_source_path_relative's strip_prefix fails because
# /tmp/build1/... is not under the CWD)
grep -c "/tmp/build1" /tmp/build1/debug/build/cranelift-codegen-*/out/isle_x64.rs
# → 297 matches — all from OUT_DIR paths where strip_prefix failed
Environment

Discovered building wasmtime 32.0.0 via Bazel (rules_rust) with sandboxed execution

Confirmed present on main (d5f1b973e48b)

Also reproducible with standard Cargo using different --target-dir values

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:31):

cfallin commented on issue #13121:

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

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:33):

travisdowns commented on issue #13121:

@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.

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:42):

travisdowns edited issue #13121:

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 0694bba38 ("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 (d5f1b973e48b).

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

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:42):

travisdowns commented on issue #13121:

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

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:52):

travisdowns commented on issue #13121:

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 0694bba38, and the cranelift-assembler-x64 side doesn't need fixing.

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:52):

travisdowns closed issue #13121:

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 0694bba38 ("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 (d5f1b973e48b).

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

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:53):

travisdowns edited a comment on issue #13121:

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 0694bba38, and the cranelift-assembler-x64 side doesn't need fixing.

Sorry for the noise!

Last updated: May 03 2026 at 22:13 UTC

Stream: git-wasmtime

Topic: wasmtime / issue #13121 cranelift build scripts embed abs...

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:26):

Summary

Affected crates

1. `cranelift-assembler-x64`

2. `cranelift-codegen`

Impact

Reproducer

Environment

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:27):

Summary

Affected crates

1. `cranelift-assembler-x64`

2. `cranelift-codegen`

Impact

Reproducer

Environment

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:31):

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:33):

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:42):

Summary

Status

`cranelift-assembler-x64`

Impact

Reproducer

Environment

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:42):

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:52):

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:52):

Summary

Status

`cranelift-assembler-x64`

Impact

Reproducer

Environment

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:53):

Stream: git-wasmtime

Topic: wasmtime / issue #13121 cranelift build scripts embed abs...

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:26):

Summary

Affected crates

1. cranelift-assembler-x64

2. cranelift-codegen

Impact

Reproducer

Environment

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:27):

Summary

Affected crates

1. cranelift-assembler-x64

2. cranelift-codegen

Impact

Reproducer

Environment

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:31):

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:33):

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:42):

Summary

Status

cranelift-assembler-x64

Impact

Reproducer

Environment

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:42):

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:52):

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:52):

Summary

Status

cranelift-assembler-x64

Impact

Reproducer

Environment

Wasmtime GitHub notifications bot (Apr 16 2026 at 02:53):

1. `cranelift-assembler-x64`

2. `cranelift-codegen`

1. `cranelift-assembler-x64`

2. `cranelift-codegen`

`cranelift-assembler-x64`

`cranelift-assembler-x64`