Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
brson opened this issue Sep 6, 2016 · 10 comments
Closed
Labels

Comments

@brson
Copy link
Contributor

brson commented Sep 6, 2016

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
Copy link
Contributor Author

brson commented Sep 6, 2016

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

@kripken
Copy link
Member

kripken commented 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-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
Copy link

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
Copy link
Contributor Author

brson commented 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.

bors added a commit to rust-lang/rust that referenced this issue Oct 1, 2016
Working asmjs and wasm targets

This patch set results in a working standard library for the asmjs-unknown-emscripten and wasm32-unknown-emscripten targets. It is based on the work of @badboy and @rschulman.

It does a few things:

- Updates LLVM with the emscripten [fastcomp](rust-lang/llvm#50) patches, which include the pnacl IR legalizer and the asm.js backend. This patch is thought not to have any significant effect on existing targets.
- Teaches rustbuild to correctly link C code with emscripten
- Updates gcc-rs to work correctly with emscripten
- Teaches rustbuild to run crate tests for emscripten with node
- Modifies Thread::new to return an error on emscripten, to facilitate debugging a common failure mode
- Modifies libtest to run in single-threaded mode for emscripten
- Ignores a host of tests that don't work yet, mostly dealing with threads and I/O
- Updates libc with wasm32 definitions (presently the same as asmjs)
- Adds a wasm32-unknown-emscripten target that feeds the output of LLVM's asmjs backend through emcc to generate wasm

Notes and caveats:

- This is only known to work with `--enable-rustbuild`.
- The wasm32 target can't be tested correctly yet because of issues in compiletest and limitations in node emscripten-core/emscripten#4542, but hello.rs does seem to work when run on node via the binaryen interpreter
- This requires an up to date installation of the emscripten sdk from its incoming branch
- Unwinding is very broken
- When enabling the emscripten targets jemalloc is disabled for all targets, which results in test failures for the host

Next steps are to fix the jemalloc issue, start building the two emscripten targets on the auto builders, then start producing nightlies.

#36317 tracks work on this.

Fixes #36515
Fixes #36515
Fixes #36356
bors added a commit to rust-lang/rust that referenced this issue Jun 16, 2017
Add a travis builder for wasm32-unknown-emscripten

This commits add an entry to travis matrix that will execute wasm32-unknown-emscripten tests suites.

- Emscripten for asmjs was updated to sdk-1.37.13-64bit
- The tests are run with node 8.0.0 (it can execute wasm)
- A wrapper script is used to run each test from the directory where it is (workaround for emscripten-core/emscripten#4542)
- Some tests are ignore, see #42629 and #42630
@patrickroberts
Copy link

patrickroberts commented Jul 8, 2018

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
Copy link
Contributor

nazar-pc commented Jul 8, 2018

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

@patrickroberts
Copy link

@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
Copy link
Contributor

nazar-pc commented 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
Copy link
Contributor

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
Copy link

stale bot commented 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.

@stale stale bot added the wontfix label Sep 18, 2019
@stale stale bot closed this as completed Sep 26, 2019
josephlr added a commit to josephlr/cross that referenced this issue Jan 5, 2021
Emscripten and rustc have to use compatible versions of LLVM to avoid
linker error. With the update to LLVM 11, emscripten also requires an
update, see rust-lang/rust#75716.

Also, now the emscripten is updated, the fix for
emscripten-core/emscripten#4542 is now avalibe, which
means we can delete the node-wasm workaround.

Signed-off-by: Joe Richey <joerichey@google.com>
Emilgardis pushed a commit to Emilgardis/cross that referenced this issue Feb 6, 2022
Emscripten and rustc have to use compatible versions of LLVM to avoid
linker error. With the update to LLVM 11, emscripten also requires an
update, see rust-lang/rust#75716.

Also, now the emscripten is updated, the fix for
emscripten-core/emscripten#4542 is now avalibe, which
means we can delete the node-wasm workaround.

Signed-off-by: Joe Richey <joerichey@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants