I suspect that is not a missing export, but could be a more serious bug in the compiler (a missing export would likely show up as "Module.X is not a function").
1.39.0 changed the default backend, and in particular the non-wasm output is now emitted by the "wasm2js" tool instead of the old asm.js backend. So I suspect this might be a wasm2js bug. I'd suggest building with --profiling. Does the problem still happen there? If so, the function name may be more helpful. Otherwise, bisection on versions may be useful, to verify if 1.39.0 is where this broke (which is where the default backend switched). Another option is to change the backends on the current version - install 1.39.3-fastcomp vs 1.39.3 (the default is 1.39.3-upstream, the new backend). Regardless, if this is a wasm2js bug (as I suspect it is), if you can provide the input files for the link stage, plus the link command, so I can reproduce it locally, that would be great! - Alon On Tue, Nov 19, 2019 at 2:54 PM Eric Mandel <[email protected]> wrote: > I upgraded from 1.38.37 to 1.39.3 and was very pleased to see the llvm > back-end report two "multiply defined" errors in the link phase. Thanks > very much! Unfortunately, we also still need to support a non-wasm version > because of problems integrating into Jupyter notebooks. But when I compile > with -O3, I get a runtime error in the browser (not involving Jupyter): > > Uncaught TypeError: Ba is not a function > at eC (astroem.js:64) > at iC (astroem.js:64) > at Wn (astroem.js:60) > at Gf (astroem.js:40) > at Wg (astroem.js:40) > at Fc (astroem.js:12) > at dk (astroem.js:20) > at Module._openFITSFile (astroem.js:86) > at ccall (astroem.js:86) > at FileReader.fileReader.onload (astroem.js:86) > > This error was not present in 1.38.37 (wasm and non-wasm), and it is not > present when building the 1.39.3 wasm version. Surprisingly, it does not > happen if I use -O2 (or -O3 -g) in the last phase of the build, which is > the current work-around. > > I'd appreciate help in understanding how to identify and possibly fix > this. The missing routine is far too deep in the call stack to be something > I would think to add to the EXPORTED_FUNCTIONS array. I didn't quite see > how to use the output of the --emit-symbol-map, but I could see a number of > differences in the list of routines between -O2 and -O3. > > > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/2ded49dc-940e-46a6-9bee-8091befdda43%40googlegroups.com > <https://groups.google.com/d/msgid/emscripten-discuss/2ded49dc-940e-46a6-9bee-8091befdda43%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTttunJWKJdjzuodbE6FTZTZ3dOtx7Aqbh-X532hbE4aw%40mail.gmail.com.
