Error executing tsembind

[ssg3d]

Running tsembind <myfilegeneratedbyemscripten.js> fails with the following error:

failed to asynchronously prepare wasm: LinkError: WebAssembly.instantiate(): Import #114 module="env" function="memory" error: memory import must be a WebAssembly.Memory object
LinkError: WebAssembly.instantiate(): Import #114 module="env" function="memory" error: memory import must be a WebAssembly.Memory object
RuntimeError: abort(LinkError: WebAssembly.instantiate(): Import #114 module="env" function="memory" error: memory import must be a WebAssembly.Memory object) at Error
<stack....>

[ted537]

Thanks for submitting the issue! What linker flags are you using? I'd be especially curious about -s MODULARIZE and -s EXPORT_ES6 and similar.

[ssg3d]

Actually none of those. Here is my build script:

../../emsdk/upstream/emscripten/em++ \
-s USE_WEBGL2 \
-s ALLOW_MEMORY_GROWTH=1 \
-I ../../glm/glm \
-I ../../json \
--bind -o ../public/<my>.js \
<all cpp files>
echo Done!

[ted537]

Hmm it looks like I may be doing some generic object reconstruction which is losing type info. I suspect that -s ALLOW_MEMORY_GROWTH=1 causes Emscripten to pass in a custom WebAssembly.Memory object.

Hopefully this is a simple fix.

[ted537]

What's the output of em++ -v ?

[ssg3d]

output.txt
Output attached. I have replaced path with <PROJECT_DIR> and name with <PROJECT_NAME>.

[ted537]

It looks like you are using Emscripten 1.39. Does the issue still occur if you update Emscripten?

[ssg3d]

Ok, let me update to latest and try it out again.

[ssg3d]

It worked! The file looks neat!
I havent yet replaced my manual ts file with this, I plan to do this next and compile. But I noticed that intellisense complains at "export class {constructor(): ; ...etc...}", possibly is an error?

[ssg3d]

A suggestion - could you add an example usage on your github page? Emscripten expects us to create a Module object with onRuntimeInitialized function, so it may be useful to have a quick reference on how to adapt to it.

[ted537]

1. The intellisense warnings may very well be correct. The declarations may need some polishing
2. The declaration layer always exports a promise, as it (hastily) assumes that -s MODULAR is being used

[ted537]

#6 should solve this. I'm pretty busy at the moment but always open to contributions

[ted537]

How are you accessing the module?

const Module = require('mymodule.js')
Module.f()

OR

require('mymodule.js')
window.Module.f()

[ssg3d]

Am using emscripten for my front end code. Simple js + wasm, no node js. “A quick example” at https://emscripten.org/docs/porting/connecting_cpp_and_javascript/embind.html sums it.

[ted537]

Hmm, ok. I suppose we would need a manual option for this then, since Emscripten's JS file can be run either in a browser or NodeJS context

[ted537]

On second thought, there appear to be quite a few ways to consume the library, so it may be simpler to add the window level export in your own .d.ts file that wraps the provided one. Assumptions like "do we always assume the library has been initialized?" should probably be answered on a per-use case basis, I believe.