Compilation error: Implementation limit exceeded

[whitequark]

Some people get this error while instantiating a WASM module, all of them on Windows, e.g. see here. Unfortunately it is quite opaque and I'm not really sure where to go from here, especially since wasmtime-py ignores RUST_LOG. How do I debug this?

[tschneidereit]

That's probably bytecodealliance/wasmtime#1734, so should hopefully be fixed once that PR lands.

@alexcrichton would it be feasible to have wasmtime-py respect RUST_LOG?

[alexcrichton]

I've opened bytecodealliance/wasmtime#1737 to get RUST_LOG working, and otherwise @tschneidereit is right that PR should fix the underlying issue too!

[alexcrichton]

Ok I'm going to close this in favor of bytecodealliance/wasmtime#1734 and the upstream issue at bytecodealliance/wasmtime#1587, since I believe those should cover the issues here.

[peterhuene]

@whitequark the fix for this issue was just merged. Please let me know if you're still running into an issue on Windows. Thanks!

[whitequark]

I can confirm this fixes the Windows issue.

@alexcrichton Is there a chance we can have a wasmtime release?

[alexcrichton]

Sure yeah, I pushed a 0.16.1 tag which is the exact same as the 0.16.0 tag but should download the latest copies of the C API. We've had some breaking API changes so I'm going to hold off until 0.17.0 of wasmtime itself before publishing that for this extension.

CI isn't running, however, so I'm going to need to debug that...

[alexcrichton]

Ok published now!

[cr1901]

I can confirm that wasmtime-py and wasmtime are fixed on my end on mingw via a manual install. Just for the sake of knowing, is there any particular reason that if you install manually you have to download wasmtime into your source directory instead of wasmtime being installed into site-packages?

[alexcrichton]

The wasmtime dynamic library needs to be downloaded to wherever wasmtime-py is installed to, and it you're manually installing it that may explain the oddness?