Stream: general

Topic: ✔ spidermonkey-wasm-rs

Jerome Gravel-Niquet (Nov 14 2022 at 14:06):

I'm trying to compile the repl-example from https://github.com/bytecodealliance/spidermonkey-wasm-rs and running into a few issues. I solved a bunch of them by pinning the dependencies, but I think there have been too many changes to Rust since then and I can't seem to compile it. I'm stuck at rust-lld errors like:

rust-lld: error: duplicate symbol: rust_oom
>>> defined in /Users/jerome/src/github.com/jeromegn/spidermonkey-wasm-rs/target/wasm32-wasi/debug/deps/libspidermonkey_wasm_sys-14bbb70c973c749d.rlib(std-b2d023322055224f.std.79e0684a-cgu.0.rcgu.o)
>>> defined in /Users/jerome/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-wasi/lib/libstd-865c3399b8bb5e0b.rlib(std-865c3399b8bb5e0b.std.24c1e981-cgu.0.rcgu.o)

Jerome Gravel-Niquet (Nov 14 2022 at 14:44):

It looks like the same symbols are defined in both spidermonkey-wasm-sys and libstd provided by rust for the wasm32-wasi target.

bjorn3 (Nov 14 2022 at 15:47):

Looks like spidermonkey now uses rust which causes it to embed a copy of the rust standard library. This copy then ends up in libspidermonkey_wasm_sys.rlib when it statically links to spidermonkey. When linking libspidermonkey_wasm_sys.rlib this then causes a conflict with the libstd.rlib of the current rust toolchain.

bjorn3 (Nov 14 2022 at 15:51):

In your specific case it also looks like both libstd are coming from different rustc versions, which is pretty much guaranteed to give issues even if you somehow were able to make the linker prefer one symbol over the other.

Jerome Gravel-Niquet (Nov 14 2022 at 15:54):

Interesting! That makes sense. Would using the same Rust version help at all? I assume it would since the last commit pushed to the spidermonkey-wasm-rs repo had its build pass

Jerome Gravel-Niquet (Nov 14 2022 at 15:54):

and it must've been using the same Rust version as the checked-out spidermonkey source

Jerome Gravel-Niquet (Nov 14 2022 at 15:57):

image.png

bjorn3 (Nov 14 2022 at 16:21):

Using the same rust version may help, but only by accident. There is no guarantee that even for the same rustc version linking a rust staticlib into a crate will work. In fact it likely won't if you use for example #[global_allocator].

Saúl Cabrera (Nov 15 2022 at 02:20):

Every FireFox release supports a specific Rust version the bindings are still using SpiderMonkey v 96, so it should work if you use Rust 1.57.

Jerome Gravel-Niquet (Nov 15 2022 at 13:16):

Saúl Cabrera said:

Every FireFox release supports a specific Rust version the bindings are still using SpiderMonkey v 96, so it should work if you use Rust 1.57.

That's likely going to be easier than compiling spidermonkey from the latest HEAD :) I'll give that a try!

Jerome Gravel-Niquet (Nov 15 2022 at 13:44):

Yes, that did it.

Notification Bot (Nov 15 2022 at 13:44):

Jerome Gravel-Niquet has marked this topic as resolved.

Jerome Gravel-Niquet (Nov 15 2022 at 14:17):

@Saúl Cabrera any idea if compiling a more recent spidermonkey from the gecko-dev repo would still work if i used the same Rust version they used? I assume this is because the pre-built spidermonkey-wasm was built with rust 1.57. I'm slightly concerned (but not much, I'm just playing with this project at this point) by @bjorn3 's comments regarding compiling duplicate symbols.

Saúl Cabrera (Nov 15 2022 at 15:11):

Yeah, that should work. The process of updating SpiderMonkey for the bindings entails ensuring that they are built using the supported Rust version by a given SpiderMonkey version, that's generally the best workaround I know for the duplicate symbols issue.

Last updated: Nov 22 2024 at 16:03 UTC