cargo: Cargo does not provide a .wasm file in the correct location when building for wasm32-unknown-emscripten
When building a project with the wasm32-unknown-emscripten target:
cargo build --target=wasm32-unknown-emscripten
a .js file is output in the target/wasm32-unknown-emscripten/debug folder, but not a corresponding .wasm file.
Instead, the .wasm file appears in the target/wasm32-unknown-emscripten/debug/deps folder, named with the metadata suffix.
The expected behavior would be to output both the .js and .wasm in the debug folder. The .js loader file is also trying to load .wasm file from its own folder with the metadata suffix.
If you run rustc --target=wasm32-unknown-emscripten --print=file-names main.rs, you’ll see that rustc only prints main.js as an output file, even though emscripten will produce both main.js and main.wasm.
cargo 0.23.0-nightly (8118b02ac 2017-09-14)
rustc 1.22.0-nightly (26015da01 2017-09-23)
x86_64-pc-windows-msvc
emcc 1.37.21
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 2
- Comments: 16 (14 by maintainers)
Commits related to this issue
- Handle target specific outputs such as .wasm or .dll.lib Fixes #4500, #4535 Until now, Cargo does not have any knowledge about target-specific output files. It relies solely on rustc for this sort o... — committed to tatsuya6502/cargo by tatsuya6502 7 years ago
- Handle target specific outputs such as .wasm Fixes #4535 - Do not add metadata to wasm32 bin target because generated .js will refer corresponding .wasm. - Handle different usages of "-" and "_" i... — committed to tatsuya6502/cargo by tatsuya6502 7 years ago
- Auto merge of #4570 - tatsuya6502:target-specific-artifacts, r=alexcrichton Handle target specific outputs such as .wasm or .dll.lib Fixes #4500, #4535 Until now, Cargo does not have any knowledge ... — committed to rust-lang/cargo by bors 7 years ago
Yes, I submitted it as a PR (#4570). But before it gets merged, I think one of us needs to verify that it actually solves the problem. The PR contains fixes for wasm and Windows DLL (#4500), and I verified the latter. I cannot verify the earlier because I do not have emscripten now.
@derekdreery indeed! So up to this point we’ve avoided encoding anything target-specific in Cargo, it relies solely on rustc for this sort of information. That being said I think it’s time to break that rule! If Cargo were to handle this then I believe yeah, that location is where the fix would go.
I tested x86_64-pc-windows-msvc, works great now! Thank you!