Repository navigation
Running wasm output via node does not work when in a different directory #4542
Description
The Rust test suite runs tests using commands like
node build/x86_64-unknown-linux-gnu/test/run-pass/hello.stage2-wasm32-unknown-emscripten.js
This results in the following error:
trying binaryen method: native-wasm
no native wasm support detected
trying binaryen method: interpret-binary
/mnt2/dev/rust/build/x86_64-unknown-linux-gnu/test/run-pass/hello.stage2-wasm32-unknown-emscripten.js:118988
throw ex;
^
Error: ENOENT: no such file or directory, open 'hello.stage2-wasm32-unknown-emscripten.wasm'
at Error (native)
at Object.fs.openSync (fs.js:549:18)
at Object.fs.readFileSync (fs.js:397:15)
at Object.read (/mnt2/dev/rust/build/x86_64-unknown-linux-gnu/test/run-pass/hello.stage2-wasm32-unknown-emscripten.js:118954:37)
at Object.readBinary (/mnt2/dev/rust/build/x86_64-unknown-linux-gnu/test/run-pass/hello.stage2-wasm32-unknown-emscripten.js:118959:29)
at getBinary (/mnt2/dev/rust/build/x86_64-unknown-linux-gnu/test/run-pass/hello.stage2-wasm32-unknown-emscripten.js:118715:36)
at doWasmPolyfill (/mnt2/dev/rust/build/x86_64-unknown-linux-gnu/test/run-pass/hello.stage2-wasm32-unknown-emscripten.js:118796:14)
at Object.Module.asm (/mnt2/dev/rust/build/x86_64-unknown-linux-gnu/test/run-pass/hello.stage2-wasm32-unknown-emscripten.js:118862:23)
at Object.<anonymous> (/mnt2/dev/rust/build/x86_64-unknown-linux-gnu/test/run-pass/hello.stage2-wasm32-unknown-emscripten.js:124211:1)
at Module._compile (module.js:434:26)
This instead works successfully:
(cd build/x86_64-unknown-linux-gnu/test/run-pass/ && node hello.stage2-wasm32-unknown-emscripten.js)
I suspect I can work around this by changing the directory in our test runner.
Activity
brson commentedon Sep 6, 2016
This is actually quite ugly to work around in our test runner.
kripken commentedon Sep 6, 2016
Yeah, sorry about this. I'm not sure what we can do to improve. On both node.js and on the web, there isn't a
__file__type thing like C and Python have, which would let us find the dir of the js file and use that to find the wasm file alongside it. So we just look in the current dir.One specific possibility is you can add some code using
--pre-jsthat createsModule.locateFile. That method gets a filename it wants, and can return a different path where to find it. But, this might be uglier than the hacks you already have in mind.rschulman commentedon Sep 7, 2016
I'm not sure that it will be as ugly as you thought at first glance, @brson.
I think that there may be a solution in
compiletest/procsrv.rs.std::process::Commandcan take a directory to run in, thoughprocsrvdoesn't bother because it doesn't need it. We could either modifyprocsrv::run()to take aOption<Path>as a target directory and rewrite all the other calls to includeNoneif it doesn't need it, or create a newprocsrv::run_with_dir()to be used just in the wasm/node case.Do you think that would fix the problem we're seeing? Or is there only one way to find out?
brson commentedon Sep 7, 2016
@rschulman Yes, either of those solutions should work. The only thing I suspect might cause problems is the various paths being passed around - if any of them are relative things could break. But let's just try and see what happens.
patrickroberts commentedon Jul 8, 2018
At least in Node.js, you have
__dirname, which would resolve the path resolution issue thatprocess.cwd()is causing.fs.readFileSync(…)implicitly usesprocess.cwd()for relative paths, but if you changed the call tofs.readFileSync(path.resolve(__dirname, …)), this problem would go away in Node.js.nazar-pc commentedon Jul 8, 2018
@patrickroberts, #5368 fixes this issue. It just wasn't merged yet.
patrickroberts commentedon Jul 10, 2018
@nazar-pc thanks for letting me know. I tried to check out your fork of emscripten and rebuild emsdk with it, but the expected versions of llvm caused compilation to fail. What commit of emsdk should I fork that's compatible with your pull request?
nazar-pc commentedon Jul 10, 2018
Try to install version that was latest stable approximately at the time of last commit in that PR.
I have e1.37.33_64bit and e1.37.35_64bit installed, I think one of those should work, probably the first one.
nazar-pc commentedon Jul 15, 2018
Quick update: PR was rebased against incoming (look for commits with green tests) so that you can benefit from Emscripten's improvements over the last year. Will hopefully be merged soon.
stale commentedon Sep 18, 2019
This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.
Update emscripten version
Update emscripten version