Mismatched wasm output on darwin vs Ubuntu

[nmattia]

I tried this code:

// Crate A
use std::cell::{RefCell};
use std::collections::HashMap;

use internet_identity_interface as other;

#[export_name = "the name"]
fn dummy()
{
    let _err_info = "hello".to_string(); // Removing this makes the outputs match

    other::unreachable(); // Calling unreachable! from this crate makes the outputs match
}


pub type SomeType = u8; // Inlining 'u8' in the ASSETS below makes the outputs match

thread_local! {
    static ASSETS: RefCell<HashMap<&'static str, (Vec<SomeType>, &'static [u8])>> = RefCell::new(HashMap::default());
}

fn main() {}

// Crate B ("other")
pub fn unreachable() {
    unreachable!();
}

When building using the wasm32-unknown-unknown target, I expect the output to be the same on Ubuntu and macOS. Instead, I'm getting different outputs. I've tried on different Ubuntu and macOS versions, and the output is consistent across all versions of the same platform. What's really odd is that the slightest various of the code above makes the output match again.

This is the command I use to build:

cargo build --manifest-path ./src/path/to/Crate/A/Cargo.toml --target wasm32-unknown-unknown --release -j1

This could be a cargo issue, I'm not sure of what's happening under the hood.

Meta

rustc --version --verbose:

rustc 1.58.1 (db9d1b20b 2022-01-20)
binary: rustc
commit-hash: db9d1b20bba1968c1ec1fc49616d4742c1725b4b
commit-date: 2022-01-20
host: x86_64-apple-darwin
release: 1.58.1
LLVM version: 13.0.0

---

rustc 1.58.1 (db9d1b20b 2022-01-20)
binary: rustc
commit-hash: db9d1b20bba1968c1ec1fc49616d4742c1725b4b
commit-date: 2022-01-20
host: x86_64-unknown-linux-gnu
release: 1.58.1
LLVM version: 13.0.0

[eggyal]

When you refer to "matching outputs" do you mean the compiled wasm binaries?

I don't think rustc guarantees binary stability between compilations performed on the same machine, let alone those performed on different host platforms.

[nagisa]

Rust does not guarantee reproducible builds between compilers built from different commits, but you should be able to rely on getting reproducible builds given the same target, same toolchain versions and some --remap-path-prefix action.

---

Are you sure this isn't just an example of some host paths leaking into the wasm output?

[nmattia]

When you refer to "matching outputs" do you mean the compiled wasm binaries?

Yes!

Are you sure this isn't just an example of some host paths leaking into the wasm output?

Maybe, but when I looked at the wasm (or rather .wat) code there seemed to be differences in the code itself, not just the strings. Will have another go at it with --remap-path-prefix!

[shkoo]

Is "B" specified by relative path? It doesn't look like you included your Cargo.toml.

If it's specified by relative path my rust-lang/cargo#15122 might be a duplicate of this issue.

[mraszyk]

Building this (simpler) library also results in mismatching WASM hashes on Ubuntu and macOS:

#[no_mangle]
pub fn greet(name: i32) -> usize {
  aux(name.to_string()).len()
}

fn aux(x: String) -> String {
  format!("Hello, {}", x)
}

[brson]

I am seeing differences in simple wasm binaries when compiled with 1.79 and 1.80 on both macos and linux. I have used --remap-path-prefix and there are no differences in paths between the binaries.

The two differences I see are:

• some definitions are in a different order in the final wasm
• when not stripping symbols, most symbol names have differing hashes embedded in them. This is at least true for symbols from all the crates.io dependencies I've looked at; but notably the core library symbols seem to contain the same hashes across build platforms.

The latter seems the most important, as it could conceivably influence the former.

[brson]

I see that cargo is passing different values for -C metadata to our crates, depending on platform. There is an existing cargo issue about this: rust-lang/cargo#8140

[brson]

The above issue may be fixed by rust-lang/cargo#14107, which references #117597, which this may be a duplicate of.