Linking issues when using Emscripten + Rust + pthread #14419
Comments
|
Does removing |
|
I don't have control over those flags, it's just debug output. I think they're hardcoded in Rust compiler as part of the integration. |
Or, I guess, to clarify - I can add to the list but not remove those already there. |
|
Can you run the command directly (manually) to see if it works? Or are there temp files etc. that rust would have created that are missing? I'm just trying to find out if this is the issue or not. Another option might be to patch rust just to see what happens without that flag. Or to patch emcc.py with this: diff --git a/emcc.py b/emcc.py
index 9eebdb910..4e2b36415 100755
--- a/emcc.py
+++ b/emcc.py
@@ -563,6 +563,8 @@ def get_all_js_syms(temp_files):
def filter_link_flags(flags, using_lld):
def is_supported(f):
+ if f.startswith('-l'):
+ return False, False
if using_lld:
for flag, takes_arg in UNSUPPORTED_LLD_FLAGS.items():
# lld allows various flags to have either a single -foo or double --foo |
|
I recently made some change to how we handle If you pass The relevant changes on the emscripten side the effect this behaviour landed last week.
I think you will need to either have non of these or all these in order to fix this issue. Specifically I think any revision after #14403 should be good. |
|
Oh I see the sdk you are using is probably before any of those changes. Do you have the emscripten revision that you are using by chance? |
|
Its probably not very interesting to you, but passing |
|
This is using a version between |
|
Yeah looks like I can and removing This problem is familiar though - it's because Rust is shipping prebuild stdlib without those Wasm features, so it ends up being incompatible. It's an issue for the Let me try that... |
Rust doesn't always link to libc - it depends on the system - so I think it's just not special-casing it in any way and links in the same way as any other discovered external dependency. |
Okay, if I do that (with nightly Rust), I'm running into a different issue: |
|
"Bad relocation type" may be due to using incompatible LLVMs. So we need to figure out if Rust is using LLVM from July 2020 or April 2021. If it's the latter, then trying |
|
Please try with 2.0.13, which is the first release after llvmorg-13-init (see #14394 (comment)). |
|
Running again into So again, I copy-paste command and manually remove |
|
Can you include the full failing link command? |
|
You could also give |
Sure: FWIW that's the same error that was reported by someone on StackOverflow (which is where this whole investigation started): https://stackoverflow.com/questions/67474533/error-in-compiling-rust-into-webassembly-using-emscripten-on-windows |
I think that's compile-time flag? I can't modify those if so (well I probably can via those env vars you once shown me, but that's not very accessible). I can only add link flags in the config. That said, it looks like command already has Trying |
|
It didn't give me more details (or maybe missed it), but removing It's all pretty difficult right now due to those issues, but it's good to know it can work. I've pushed changes and description of issues to the same repo if someone wants to take a look and play with it: https://github.com/RReverser/emscripten-rust-test |
|
May be fixed by disabling the duplicate error abort. See comment - rust-lang/rust#85821 (comment) |
|
Looks like the original repo now compiles & runs successfully, so closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've uploaded a sample trying to use
std::threadAPI in Rust + Emscripten here: https://github.com/RReverser/emscripten-rust-testHere's what my config looks like - I ended up enabling atomics feature for Rust to know it's compiled with threads support, and linking
-pthreadfor Emscripten: https://github.com/RReverser/emscripten-rust-test/blob/38d01ad5f80b95f0c2168791667cc32cf721039a/.cargo/config#L2When trying to build it with emsdk version from #14394, it fails with linking errors suggesting conflict between regular
libcandlibc-mt:@kripken @tlively
The text was updated successfully, but these errors were encountered: