Emscripten RTTI bug about oryol HOT 4 OPEN

Hmm... I haven't worked with side modules yet, but I don't believe they have their own address space, that would isolate them completely from the main module and other side modules. As far as I can see from the documentation the difference is that they are 'pure code', without attached runtime (I guess they access the shared runtime from the main module)

I suspect instead that something's wrong about the allocation of the static char _type_id; here when running in the context of a side module:

Maybe the side module's static "allocation counter" is running independent from the main module (and other side modules), so that statics setup in the main and side modules end up in the same memory location.

from oryol.

PS: also googling for smth like "emscripten side module static initialization" brings up this fairly recent bug:

emscripten-core/emscripten#6991

Is your emscripten version uptodate?

from oryol.

Yeah - locally I build with the incoming branch as per fips's default, and I have a script for Travis that patches fips to use 1.38.12, which is already after the bug was fixed (definitely fixed before 1.38.11 according to that).

from oryol.

One (unpleasant) option is an alternative system for Emscripten: global symbols are clearly visible from side modules - I use ImGui built into my main module from my plugins - so we could set a global int - a 32-bit number should be plenty (even if it's an extra 3 bytes per class), and have each class declare a static int that's initialized to the global from the main module ++ on startup. That quadruples the size of the RTTI, but should (if implemented properly) work as a temporary hack until this bug is fixed in Emscripten.

from oryol.