-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Don't link with --export-dynamic on wasm32-wasi #81255
Conversation
Remove --export-dynamic from the link arguments on the wasm32-wasi target, as it emits spurious exports and increases code size. Leave it in place for wasm32-unknown-unknown and wasm32-unknown-emscripten. Even though it isn't a great solution there, users are likely depending on its behavior there.
r? @davidtwco (rust-highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation looks good to me but can't speak to whether the change is appropriate.
@bors: r+ |
📌 Commit 9abcfa5 has been approved by |
⌛ Testing commit 9abcfa5 with merge e60c535320e85d27f58918a87df082c1c17eceda... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
… r=alexcrichton Don't link with --export-dynamic on wasm32-wasi Remove --export-dynamic from the link arguments on the wasm32-wasi target, as it emits spurious exports and increases code size. Leave it in place for wasm32-unknown-unknown and wasm32-unknown-emscripten. Even though it isn't a great solution there, users are likely depending on its behavior there.
… r=alexcrichton Don't link with --export-dynamic on wasm32-wasi Remove --export-dynamic from the link arguments on the wasm32-wasi target, as it emits spurious exports and increases code size. Leave it in place for wasm32-unknown-unknown and wasm32-unknown-emscripten. Even though it isn't a great solution there, users are likely depending on its behavior there.
… r=alexcrichton Don't link with --export-dynamic on wasm32-wasi Remove --export-dynamic from the link arguments on the wasm32-wasi target, as it emits spurious exports and increases code size. Leave it in place for wasm32-unknown-unknown and wasm32-unknown-emscripten. Even though it isn't a great solution there, users are likely depending on its behavior there.
…as-schievink Rollup of 11 pull requests Successful merges: - rust-lang#80092 (2229: Fix issues with move closures and mutability) - rust-lang#80404 (Remove const_in_array_repeat) - rust-lang#81255 (Don't link with --export-dynamic on wasm32-wasi) - rust-lang#81480 (Add suggestion for nested fields) - rust-lang#81549 (Misc ip documentation fixes) - rust-lang#81566 (Add a test for rust-lang#71202) - rust-lang#81568 (Fix an old FIXME in redundant paren lint) - rust-lang#81571 (Fix typo in E0759) - rust-lang#81572 (Edit multiple error code Markdown files) - rust-lang#81589 (Fix small typo in string.rs) - rust-lang#81590 (Stabilize int_bits_const) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: bytecodealliance/wasmtime#2587 As a workaround, it is possible to specify the `--allow-unknown-exports` flag on wasmtime. But as discussed in the above linked issue, this seems to only be a workaround. For the Rust compiler the fix was to remove the `--export-dynamic` linker flag when targeting `wasm32-wasi`: rust-lang/rust#81255 Which is waht this commit does for Tinygo too.
Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: bytecodealliance/wasmtime#2587 As a workaround, it is possible to specify the `--allow-unknown-exports` flag on wasmtime. But as discussed in the above linked issue, this seems to only be a workaround. For the Rust compiler the fix was to remove the `--export-dynamic` linker flag when targeting `wasm32-wasi`: rust-lang/rust#81255 Which is waht this commit does for Tinygo too.
Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: bytecodealliance/wasmtime#2587 As a workaround, it is possible to specify the `--allow-unknown-exports` flag on wasmtime. But as discussed in the above linked issue, this seems to only be a workaround. For the Rust compiler the fix was to remove the `--export-dynamic` linker flag when targeting `wasm32-wasi`: rust-lang/rust#81255 Which is waht this commit does for Tinygo too.
Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: bytecodealliance/wasmtime#2587 As a workaround, it is possible to specify the `--allow-unknown-exports` flag on wasmtime. But as discussed in the above linked issue, this seems to only be a workaround. For the Rust compiler the fix was to remove the `--export-dynamic` linker flag when targeting `wasm32-wasi`: rust-lang/rust#81255 Which is waht this commit does for Tinygo too.
Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: bytecodealliance/wasmtime#2587 As a workaround, it is possible to specify the `--allow-unknown-exports` flag on wasmtime. But as discussed in the above linked issue, this seems to only be a workaround. For the Rust compiler the fix was to remove the `--export-dynamic` linker flag when targeting `wasm32-wasi`: rust-lang/rust#81255 Which is waht this commit does for Tinygo too.
Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: bytecodealliance/wasmtime#2587 As a workaround, it is possible to specify the `--allow-unknown-exports` flag on wasmtime. But as discussed in the above linked issue, this seems to only be a workaround. For the Rust compiler the fix was to remove the `--export-dynamic` linker flag when targeting `wasm32-wasi`: rust-lang/rust#81255 Which is waht this commit does for Tinygo too.
Exporting symbols seems to embed them in the WASM exports section which causes wasmtime to fail: bytecodealliance/wasmtime#2587 As a workaround, it is possible to specify the `--allow-unknown-exports` flag on wasmtime. But as discussed in the above linked issue, this seems to only be a workaround. For the Rust compiler the fix was to remove the `--export-dynamic` linker flag when targeting `wasm32-wasi`: rust-lang/rust#81255 Which is waht this commit does for Tinygo too.
Remove --export-dynamic from the link arguments on the wasm32-wasi
target, as it emits spurious exports and increases code size.
Leave it in place for wasm32-unknown-unknown and
wasm32-unknown-emscripten. Even though it isn't a great solution
there, users are likely depending on its behavior there.