Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.58-git
Description:
Since PR #21775 (and Emscripten 3.1.58), the incoming Module is not modified in modularize builds.
Code that previously loaded additional file packages (by loading their .js) prior to instantiation of the compiled emscripten module - and worked in Emscripten < 3.1.58 - now fails. This path leads to the file package's runWithFS() being registered for preRun, but runWithFS() then apparently does not access the "actual" Module object which has FS_createPath (etc) added.
However, there appears to be a very simple fix:
callRuntimeCallbacks already passes the actual Module, so by using it in runWithFS(), the issue is resolved.
Proposed PR: #22086
EDIT:
@sbc100 While I just noticed that PR #21775 was reverted more recently, the above PR seems to fix the issue for this use-case, and it certainly seems to me like runWithFS() should be using the passed-in Module argument in any case?
Version of emscripten/emsdk: emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.58-git
Description:
Since PR #21775 (and Emscripten 3.1.58), the incoming
Moduleis not modified in modularize builds.Code that previously loaded additional file packages (by loading their .js) prior to instantiation of the compiled emscripten module - and worked in Emscripten < 3.1.58 - now fails. This path leads to the file package's
runWithFS()being registered forpreRun, butrunWithFS()then apparently does not access the "actual" Module object which hasFS_createPath(etc) added.However, there appears to be a very simple fix:
callRuntimeCallbacksalready passes the actualModule, so by using it inrunWithFS(), the issue is resolved.Proposed PR: #22086
EDIT: @sbc100 While I just noticed that PR #21775 was reverted more recently, the above PR seems to fix the issue for this use-case, and it certainly seems to me like runWithFS() should be using the passed-in Module argument in any case?