`extern` symbols are always mangled on `wasm32-unknown-emscripten`
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
Attempting to compile a program with EMCC_CFLAGS="-s ERROR_ON_UNDEFINED_SYMBOLS=0" cargo build --target wasm32-unknown-emscripten --release results in all extern functions having unpredictable names, whether or not they have #[no_mangle].
I tried this code:
extern "C" {
fn foo() -> f64;
}
fn main() {
println!("{}", unsafe { foo() });
}
I expected to see this happen: A generated .js loader with a stub in wasmImports["foo"].
Instead, this happened: The js loader renames the function to a practically random symbol. In this case:
function _foo() {
abort("missing function: foo")
}
_foo.stub = true;
var wasmImports = {
// .. more
y: _foo,
// .. more
};
Meta
Tested against 1.83.0 and latest nightly.
rustc --version --verbose:
rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: aarch64-apple-darwin
release: 1.83.0
LLVM version: 19.1.1
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the issue with the shown extern "C" example, the wasm32-unknown-emscripten target, and EMCC_CFLAGS="-s ERROR_ON_UNDEFINED_SYMBOLS=0". Inspect the compiler and target-specific handling of the extern symbol, then verify that the generated JavaScript contains wasmImports["foo"] rather than a renamed symbol.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust, wasm
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100