RuntimeError: Aborted(free() called but not included in the build - add '_free' to EXPORTED_FUNCTIONS) about datachannel-wasm HOT 6 CLOSED

-s EXPORTED_FUNCTIONS=["_free"] seems to have done the trick, thanks!

I still will get an ReferenceError: dynCall is not defined if I try to compile it without the -sDYNCALLS=1 flag

from datachannel-wasm.

Oh, this only seems to be a problem with newer versions of emscripten. Trying out an old version of emscripten like 2.0.3, there's no need for -sDYNCALLS=1, and there's no complications in calling free()

from datachannel-wasm.

According to their changelog at https://emscripten.org/docs/introducing_emscripten/release_notes.html#changelog:

2.0.4: 09/16/2020

• First release with Bazel support.
• Stop including malloc and free by default. If you need access to them from
  JS, you must export them manually using
  -s EXPORTED_FUNCTIONS=['_malloc', ..].
• Stop running Binaryen optimizations in -O1. This makes -O1 builds a little
  larger but they compile a lot faster, which makes more sense in a "compromise"
  build (in between -O0 and higher optimization levels suitable for release
  builds). (#12178)
• Add ERROR_ON_WASM_CHANGES_AFTER_LINK option that errors if we need to do
  any work in wasm-emscripten-finalize or wasm-opt after linking. This
  can verify the link is maximally fast and also does no DWARF rewriting.
  (#12173)

from datachannel-wasm.

huh, actually looks like linking works up to emscripten 2.0.9

from datachannel-wasm.

There should be no need for DYNCALLS=1 as it enables a legacy API with functions like dynCall_vi, it is not necessary for the dynCall function:

2.0.13: 01/19/2021
------------------
 - Add back support for calling the legacy dynCall_sig() API to invoke function
  pointers to wasm functions from JavaScript. Pass -s DYNCALLS=1
  to include that functionality in the build. This fixes a regression that
  started in Aug 31st 2020 (Emscripten 2.0.2)

There is a confusion between EXPORTED_FUNCTIONS and EXPORTED_RUNTIME_METHODS: EXPORTED_FUNCTIONS makes functions accessible from the compiled C/C++ code (otherwise they might be removed to make the build smaller), and EXPORTED_RUNTIME_METHODS exposes runtime functions to JavaScript code.

Here _free ends up optimized out so you need to add it to EXPORTED_FUNCTIONS: -s EXPORTED_FUNCTIONS=["_free"]

from datachannel-wasm.

The dynCall issue should be fixed by #39

from datachannel-wasm.