Sam Clegg

@mike-lischke, does adding `-sERROR_ON_WASM_CHANGES_AFTER_LINK` and `-sWASM_BIGINT` fix the issue for you?

Can you try without `-gsource-map`?

And this was with `-sERROR_ON_WASM_CHANGES_AFTER_LINK`? i.e. did you manage to link with that flag? What other flags are you using? I know `-fsanitize=address` can cause a lot of extra locals...

I see, so this seems like an issue with `-fsanitize=address` resulting in too many locals being created. This will most likely require an upstream llvm change, and I'm not quite...

The name passed as the first argument to EMSCRIPTEN_BINDINGS doesn't really mean anything.. it just gives the generated function a unique name. So you can use whatever name you want...

I believe the `local count too large` error is coming from the wasm runtime (e.g. v8) and I don't think it configurable, no. We could perhaps have binaryen (wasm-opt) and/or...

@kohakukun can you remove share the original link command that caused the failure? Along with the failure message itself? Does it happen if you add `-O1`?

If you see the printf in the console then I don't see how the following line wouldn't be a call to malloc. You can check contents libfetch.a if you like...

I don't think the compiler would ever change a calloc to a malloc though.. that seem backwards. Something strange much be going on. What does the it looks like if...

To get `emscripten_fetch.o` you can run `ar x cache/sysroot/lib/wasm32-emscripten/libfetch.a`.