Does WebAssembly build reproducibility depend on optimizer flags?
0 reputation · 15 Apr 2024, 23:20 UTC
Goal is a repeatable WebAssembly development environment where identical source and dependency sets produce the same module artifact across builds.
WebAssembly defines a versioned binary format with code, data, import, export and custom sections. The format is deterministic in principle, but compiler and optimizer implementations commonly introduce timestamps, random IDs and non-deterministic section ordering. Reproducibility is typically pursued with pinned compiler versions, locked manifests and containerized builds, yet tools such as wasm-opt can reorder sections or emit different custom sections between runs without explicit reproducibility flags. Build flags, source map emission and debug information are not standardized across toolchains.
With version sensitivity across compiler, optimizer, runtime and WASI preview levels, it is unclear where spec guarantees end and implementation choices begin.
Does the WebAssembly specification require deterministic encoding of a module given identical inputs? Which documented optimizer or toolchain options are intended to stabilize section ordering and custom section emission? When can byte-for-byte reproducibility be assumed without implementation-specific configuration?