Running wasm output via node does not work when in a different directory

[brson]

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.

[brson]

This is actually quite ugly to work around in our test runner.

[kripken]

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-js that creates Module.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]

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::Command can take a directory to run in, though procsrv doesn't bother because it doesn't need it. We could either modify procsrv::run() to take a Option<Path> as a target directory and rewrite all the other calls to include None if it doesn't need it, or create a new procsrv::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]

@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]

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.

At least in Node.js, you have __dirname, which would resolve the path resolution issue that process.cwd() is causing. fs.readFileSync(…) implicitly uses process.cwd() for relative paths, but if you changed the call to fs.readFileSync(path.resolve(__dirname, …)), this problem would go away in Node.js.

[nazar-pc]

@patrickroberts, #5368 fixes this issue. It just wasn't merged yet.

[patrickroberts]

@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]

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]

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.