-
Notifications
You must be signed in to change notification settings - Fork 68
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
Section contractenvmetav0 not always emitted depending on profile #383
Comments
I'm unsure at this point if this is a bug in the SDK, a bug in how the token uses the SDK, or something else entirely. I was able to get this emitted by effectively duplicated the declaration of |
I ran into this issue last week and the TL;DR of my current opinion is one of:
In my testing I witnessed that this problem only happens if the release profile noted here is not used in conjunction with building with nightly. If you use the following release profile the problem should be resolved for now: [profile.release]
opt-level = "z"
overflow-checks = true
debug = 0
strip = "symbols"
debug-assertions = false
panic = "abort"
codegen-units = 1
lto = true I ran out of time to open an issue about this on the rust repository, but I'll follow up with that today. |
After reading rust-lang/rust#56639, I now believe my summary above about nightly vs stable is incorrect. The comment here is likely the issue:
Ref: rust-lang/rust#56639 (comment) In the release profile we recommend, a single codegen unit is used: codegen-units = 1 This means the custom section is preserved because the unit is always passed to the linker. Given the custom section is never referenced right now, for anyone not using a single codegen unit it will be a bit random for if this issue occurs or not, because it really just depends how the Rust build system divides logic into codegen units. There is a comment in the linked issue about in what cases the custom section will be included:
|
Reopening this for the moment based on #386 (comment). |
It is emitted when building target. This is unchanged if I remove the calls to
wasm-opt
.The text was updated successfully, but these errors were encountered: