Unable to build latest on macOS Mojave with emsdk@1.38.16

[mysterycommand]

Hi there, I am trying to compile this project into a WASM module with the associated JS loader/import object so that I can use it in a bigger project as an ES module. So far I've just been trying to follow the instructions on emscripten.org and webassembly.org to get set up, but I can't get this to build. Here's how my environment is set up:

$ emcc -v
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 1.38.16
clang version 6.0.1  (emscripten 1.38.16 : 1.38.16)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Users/matt/Sites/juj/emsdk/clang/e1.38.16_64bit
INFO:root:(Emscripten: Running sanity checks)

Here's the toolchain stuff:

$ python --version
Python 2.7.15

$ node --version
v8.9.1

$ git --version
git version 2.19.1

$ java -version
java version "11.0.1" 2018-10-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

$ g++
clang: error: no input files

$ cmake
Usage

  cmake [options] <path-to-source>
  cmake [options] <path-to-existing-build>

Specify a source directory to (re-)generate a build system for it in the
current working directory.  Specify an existing build directory to
re-generate its build system.

Run 'cmake --help' for more information.

I got the "Hello, world!\n" example project working fine, but when I try to follow the instructions for this project I get this:

$ /Users/matt/Sites/juj/emsdk/emscripten/1.38.16/emmake make VERSION=latest 
/Users/matt/Sites/juj/emsdk/emscripten/1.38.16/em++ -s MODULARIZE=1 -s 'EXPORT_NAME="Box2D"' -s NO_FILESYSTEM=1 -s EXPORT_BINDINGS=1 -s RESERVED_FUNCTION_POINTERS=20 --post-js box2d_glue.js --memory-init-file 0 -s NO_EXIT_RUNTIME=1 glue_stub.cpp -s EXPORTED_RUNTIME_METHODS=[] -O3 --llvm-lto 1 --closure 1 -IBox2D_v2.3.1 box2d.bc -o build/Box2D_v2.3.1_min.js
error: undefined symbol: _ZN12b2ChainShape5ClearEv
warning: To disable errors for undefined symbols use `-s ERROR_ON_UNDEFINED_SYMBOLS=0`
error: undefined symbol: _ZN12b2MotorJoint11SetMaxForceEf
error: undefined symbol: _ZN12b2MotorJoint12SetMaxTorqueEf
error: undefined symbol: _ZN12b2MotorJoint15SetLinearOffsetERK6b2Vec2
error: undefined symbol: _ZN12b2MotorJoint16SetAngularOffsetEf
error: undefined symbol: _ZN12b2MotorJoint19SetCorrectionFactorEf
error: undefined symbol: _ZN15b2MotorJointDef10InitializeEP6b2BodyS1_
error: undefined symbol: _ZN6b2Body16SetFixedRotationEb
error: undefined symbol: _ZNK12b2MotorJoint11GetMaxForceEv
error: undefined symbol: _ZNK12b2MotorJoint12GetMaxTorqueEv
error: undefined symbol: _ZNK12b2MotorJoint15GetLinearOffsetEv
error: undefined symbol: _ZNK12b2MotorJoint16GetAngularOffsetEv
error: undefined symbol: _ZNK12b2MotorJoint19GetCorrectionFactorEv
error: undefined symbol: _ZNK13b2PulleyJoint17GetCurrentLengthAEv
error: undefined symbol: _ZNK13b2PulleyJoint17GetCurrentLengthBEv
error: undefined symbol: _ZTI15b2ContactFilter
Error: Aborting compilation due to previous errors
ERROR:root:'/Users/matt/Sites/juj/emsdk/node/8.9.1_64bit/bin/node /Users/matt/Sites/juj/emsdk/emscripten/1.38.16/src/compiler.js /tmp/tmpbov1fu.txt /Users/matt/Sites/juj/emsdk/emscripten/1.38.16/src/library_pthread_stub.js' failed (1)
make: *** [box2d.js] Error 1

I'm pretty inexperienced with C/C++ and this whole toolchain is kinda foreign to me, but what I'd really like is something like this:

WebAssembly
  .instantiateStreaming(fetch('box2d.wasm'), importObject)
  .then(obj => {
    // obj.instance (or maybe module?) is the Box2D "namespace" here?
  });

… on a scale of 1 to 10 how far off am I in my expectations? What am I missing?

[kripken]

To fix that error, the error message suggests this, which should work:

warning: To disable errors for undefined symbols use `-s ERROR_ON_UNDEFINED_SYMBOLS=0`

What you suggest about just running WebAssembly.instantiateStreaming would work for pure wasm, but not for the JS that works with it. In some cases you can get close to not having any JS, see here, but until wasm has access to JS objects it will depend on JS heavily for a lot of things.

[mysterycommand]

Hey, thanks for getting back to me! I'll give that a try. I didn't initially because disable errors sounds a little like suppress errors and I was hoping there would be an obvious way to actually fix them?

Anyway, I'll give that a try and do a bit more reading about how importObject and JS/WASM interop works.

[kripken]

Yeah, fixing the errors would be better, if you or someone has time to look into them. (Maybe a file isn't linked in, for example?) But that option would get us to the same behavior emscripten had before, so it's not making things worse.

[mysterycommand]

Okay, I forked this and created a branch that you can see in this comparison. I broke the LINK_OPTS out to multiple lines so they'd be a little easier to read and added the -s ERROR_ON_UNDEFINED_SYMBOLS=0 like you suggested.

Running $ /Users/matt/Sites/juj/emsdk/emscripten/1.38.16/emmake make VERSION=latest does generate a new build/Box2D_v2.3.1_min.wasm file, but that's it … the output ends with:

11 error(s), 5 warning(s)
ERROR:root:closure compiler failed (rc: 11)
make: *** [box2d.js] Error 1

There are several giant blocks of what looks like minified JavaScript with what look like more specific error messages in there … they look like this:

                                                                                                                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

/tmp/tmpma5o38/Box2D_v2.3.1_min.bc.o.js.pp.js.mem.js.jso.js.jso.js.jso.js:1: ERROR - variable _emscripten_bind_b2Vec3_b2Vec3_2 is undeclared

… but there's several thousand lines between them and my grep juju is failing me right now.

As far as actually fixing the errors I'd be happy to try and figure this out, but any pointers as to where they'd need to be linked in? This whole set up is new to me and between the Python and the C++ and the generated files and the IDLs and the make scripts … I'm kinda lost. I am fully willing to accept that I may be trying to bite off more than i can chew.

[kripken]

Closure compiler issues like that are tricky to debug in my experience. But you can build without closure and look for why that function isn't defined - it should be emitted from the webidl binder emitter, I think, so it's not a linking problem.

It's possible this isn't a bug here, but in the upstream webidl binder emitter - if you can get a standalone testcase showing the issue that could prove that.

However, another option is to set -s IGNORE_CLOSURE_COMPILER_ERRORS=1 to ignore those.