Sometimes creates empty wasm binaries

[de-husk]

Awesome project!

I ran into an issue trying to use it with this workspace: https://github.com/DA0-DA0/dao-contracts

It produced nearly empty optimized wasm binaries for cw20_stake and cw_core contracts.

When I tried to use them, I got this error:

Error calling the VM: Error during static Wasm validation: Wasm contract doesn't have required export: "instantiate". Exports required by VM: ["allocate", "deallocate", "instantiate"].: create wasm contract failed: invalid request

Im wondering if optimizoor is compiling them with the library feature enabled?

[mandrean]

Hey @de-husk, thanks for reporting! Appreciate it. Will have a look.

[mandrean]

Okay, found the issue. Basically this can happen in monorepos where each member of the workspace has its own lockfile, like the DA0-DA0 contracts

Current implementation assumes the monorepo shares one lockfile. Shouldn't be too difficult to support both cases

[mandrean]

I digged quite a bit deeper into this, and the lockfile hypothesis was just a coincidence. It's actually a bug(/feature) in cargo itself:
rust-lang/cargo#3620
rust-lang/cargo#8157 (comment)
rust-lang/cargo#4463
rust-lang/cargo#4866
rust-lang/cargo#10266 (comment)

ehuss commented on Jul 6, 2020
Thanks for the report! This is a known issue /.../
The --workspace flag causes all features of all workspace members to be unified.

If you have a workspace where a member (e.g. DA0-DA0/cw_core) is both a release binary and a library/dependency to some other binary, then cargo will "simplify" the dependency graph by only compiling that member (cw_core in this case) once - with the feature flag set - causing that to spill over into the release binary as well!

Looking into if there is a way to influence/work around this in an efficient way

[mandrean]

Okay @de-husk, I have a workaround! Check #5

[de-husk]

This is looking good btw. Thanks for the quick fix!

[mandrean]

Thanks for reporting the bug! Much appreciated.