-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Make Rust work with emscripten #2235
Comments
See also #3608. |
Would still be nice; not on any maturity milestone. |
Still would be nice, but is not very important. This should get easier, since a lot of the runtime is being rewritten in rust. |
See also #7282 |
Now that the runtime is written in Rust, how does that change the prospects for this bug? How hard would it be to get a runtimeless Hello World running through emscripten? |
It should not be particularly difficult to add really nice support for emscripten now. It already pretty much works with rust-core. In the compiler we need to add support for the proper target triple, set up the various target attributes correctly, then fence off the few parts of the runtime that can't currently work in js, threading and context switching. Once 1:1 scheduling mode matures a bit more we may even be able to add support for tasks via web workers, though presently it would require a different message passing solution. Depending on what parallelism support gets added to js/emscripten we may eventually be able to support rust's message passing semantics precisely. |
Thanks to |
If it's ok, I'd actually like to leave this open for now. I think that doing this would be a good step forward towards ensuring the standard library is extensible and able to run on any number of platforms. I do agree that most of the work is probably done, and this will probably need |
@alexcrichton: It won't be possible to provide the standard library's concurrency and I/O support for emscripten. At best, it could output to the console for stdout/stderr. I can't think of any things in the standard library that are going to be a good idea for an emscripten target but not a freestanding one, beyond a default allocator implementation. |
Status update: @alexcrichton Has refactored the standard library into a bunch of smaller libraries with more understandable dependencies. It should be almost trivial to get the core, alloc, rand, and collections libraries to compile to the web now. Here is how I would suggest tackling this:
That's a pretty good start! |
Ok, so I tried with the first steps, and obviously got problems right off the bat. I compiled
Not sure if I can do anything about this, or it's because we cannot use the Sorry if this is not the place to comment about this... |
I also tried with |
@Arcnor You might ask some of those who have previously compiled simple tests with emscripten about their process. I only have a few ideas.
|
The error when trying to compile There may be a way to work around this from the rust side, but based on the comments in the emscripten issue I think getting support for atomics into emscripten makes the most sense. |
If emscripten has its own platform we could perhaps cfg-out all the atomics for their single-threaded variants, but I agree that it would be nicer to have this in upstream emscripten! |
If I'm not mistaken, the new "fastcomp" backend of emscripten is a fork of LLVM (while the previous backend was just a layer above LLVM), so the LLVM version of fastcomp is probably difficult to upgrade and won't be upgraded frequently. This will be problematic if it needs to be compatible with the output of Rust. For example right now the LLVM version of fastcomp is 3.3, while the LLVM used by Rust is 3.4. The old emscripten backend is deprecated and shouldn't be used according to the official docs, so it's probably not an option to use it. |
I seem to be the only one trying to compile for emscripten for the moment. For the record, here are the things that I tried:
Unless someone has an idea, my conclusion is that we need to wait for emscripten to upgrade. |
rum seems to have it working, sorta; perhaps this will help |
Minor update: emscripten-fastcomp has been updated to LLVM 3.4, and will be updated to LLVM 3.5 later. |
@tomaka have you tried doing anything with the 3.4 version? I was able to get the rum example compiling with it, but anything more failed with unintelligible errors. |
@ibdknox 3.4 is incompatible with 3.5 |
Hm. I was able to take the output from |
Rust has been using LLVM 3.5 for a long time now. You can be lucky and have nothing incompatible get generated.
This doesn't because of incompatible IR:
|
@ibdknox http://www.reddit.com/r/rust_gamedev/comments/2n0x08/emscripten_experiments/ |
As an update, when I compile hello world with emscripten that has now been updated to 3.5, I'm getting the following:
Here's how I'm compiling:
Things that don't seem to bring in fmt generally seem to work, though. |
I've been spending my free time this last week looking into this. I read rust's book sometime between the summer and now and really liked the mechanics of the language but only recently started implementing something with it. I'm only as knowledgable about the rust compiler as to what I learned this week but hope I can contribute. So I guess the first thing to note of what I learned (but that took me a few evenings to notice) is that Rust moved to LLVM 3.6 in July. So the current versions of Rust and emscripten-fastcomp are incompatible. I tried compiling rust with
To get to this error I configured and built emscripten-fastcomp with ../configure --enable-optimized --disable-assertions --enable-targets=host,js,arm,aarch64,mips Instead of the emscripten's guide's recommended ../configure --enable-optimized --disable-assertions --enable-targets=host,js Though Rust doesn't need to be built for all targets, it currently always links against LLVM with CPU support compiled for all targets. This is a workaround for a problem that could be fixed in the future so we may not need to always compile emscripten-fastcomp with that configuration. Once I found that Rust had moved to LLVM 3.6 I looked up the last branch on rust-lang/llvm that was LLVM 3.5. https://github.com/rust-lang/llvm/tree/rust-llvm-2014-07-24 I compiled against that instead of emscripten-fastcomp, curious to see what would turn out. I got the same exact error when compiling against emscripton-fastcomp recent move to LLVM 3.5. I take this to mean that Rust is in some way incompatible with LLVM 3.5 now and I wouldn't really expect otherwise. So now we wait or have to get emscripten-fastcomp to LLVM 3.6 😉 Its worth mentioning that I downloaded an archived 0.11 copy and was able to produce LLVM IR for hello world that I took a peek at merging rust-lang/llvm into emscripten-fastcomp. At the time there 117 conflicting sections over 43 files. I mentioned getting Rust 0.11 and emcc 1.29.2 to get to the linking stage. This is the specific result: $ emcc -v hello.ll -o hello.js
INFO root: (Emscripten: Running sanity checks)
WARNING: Linking two modules of different data layouts: '/Users/zen/.emscripten_cache/libc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas '/tmp/tmpv_yB8E/hello_0.o' is 'e-p:32:32-f64:32:64-f80:128-n8:16:32'
WARNING: Linking two modules of different target triples: /Users/zen/.emscripten_cache/libc.bc' is 'asmjs-unknown-emscripten' whereas '/tmp/tmpv_yB8E/hello_0.o' is 'i686-apple-darwin'
warning: incorrect target triple 'i686-apple-darwin' (did you use emcc/em++ on all source files and not clang directly?)
warning: unresolved symbol: _ZN2io5stdio12println_args20h0caae70b0e2eb347Iol7v0_11_0E
warning: unresolved symbol: _ZN10lang_start20h70f93b7d0a75f99atre7v0_11_0E Seems emcc/fastcomp replaces dots in symbols with underscores while Rust expects to prefix with another underscore but I'm not too sure about this. The first unresolved symbol appears as So here are the next steps I'm looking to try and work on if anyone wants to take a shot at them themselves. (Or can let me know how right or wrong I am.)
|
"Merge rust-lang/llvm into emscripten-fastcomp" You might not want to do this - Emscripten is based on pnacl-llvm/pnacl-clang so you're creating a fork with patches on patches, which will probably be painful. If you're interested, you can see some detail of the branching in the investigation I did for the Emscripten merge from r33 -> r34 at emscripten-core/emscripten-fastcomp#51 (comment). I hear that pnacl is planning on tracking upstream a bit closer than before but I can't see any relevant issue in the pnacl issue tracker to update to 3.6 so it may be a while (especially given 3.6 only branched 5 days ago!)...I guess you could create an issue? If you decide against your own Emscripten fork, I see two options - waiting for pnacl or helping Emscripten get off pnacl and onto upstream. Edit: corrected 'now' to 'not'. A crucial difference. |
I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized. This issue has been moved to the RFCs repo: rust-lang/rfcs#604 |
I've spent some time poking at this problem and rustc now generates code that emscripten can translate, but the compiled javascript fails when it hits a runtime function. The next step is to start building the runtime using
emcc
as the compiler. Stub out all the things that don't build behindEMSCRIPTEN
ifdefs.Emscripten is adding a way to treat inline assembly as javascript, so all the parts of the runtime that don't build with emscripten can be implemented inline with javascript.
Alternately, we could reimplement the runtime piecemeal in javascript and not bother compiling it from C++ at all. This approach isn't recommended.
The text was updated successfully, but these errors were encountered: