> Also, this bug report may be somehow remotely related:
> https://github.com/kripken/emscripten/issues/5361
I don't think so, because in that bug undefined symbol is actually
used in runtime. But in my case undefined symbols never used in
runtime. But I think you right compiler does not understan
Also, this bug report may be somehow remotely related:
https://github.com/kripken/emscripten/issues/5361
lauantai 12. elokuuta 2017 Jukka Jylänki kirjoitti:
> I would expect unused imports to be optimized out. Perhaps this is a case
> where the compiler is not able to eliminate some function tha
I would expect unused imports to be optimized out. Perhaps this is a case
where the compiler is not able to eliminate some function that is
referencing the given object. I don't think this would work natively
either, but linker would error out at link time on a missing symbol
(similar to what you w
Chrome error:
failed to asynchronously prepare wasm: LinkError: Import #3
module="env" function="__ZN6Editor10s_instanceE" error: global import
must be a number
testing.html:160 LinkError: Import #3 module="env"
function="__ZN6Editor10s_instanceE" error: global import must be a
number
at http:/
emcc (Emscripten gcc/clang-like replacement) 1.37.18 (commit
cb2260892ddc2c73aa40dbe0821f5a8ce3f79975)
bin.js:
function __ZN6Editor10s_instanceE() {
Module["printErr"]("missing function: _ZN6Editor10s_instanceE");
abort(-1);
}
// ...
getBinaryPromise().then((function(binary) {
retur
Is that on latest Emscripten 1.37.18? That looks like a new error that
is not known. What does the generated code around that location look
like? What should __ZN6Editor10s_instanceE be, is that a singleton
pointer?
2017-08-10 6:55 GMT+03:00 Александр Гурьянов :
> Update on compile time:
> -O2 - ~
Update on compile time:
-O2 - ~60 sec
-O3 - ~7 sec
Also I try to build project with WASM=1, and it built successfully,
but I can't run it due this error:
failed to asynchronously prepare wasm: LinkError: import object field
'__ZN6Editor10s_instanceE' is not a Number testing.html:161:40
LinkError:
The source is not public, but I think I can share result js if it's useful.
I will try to build WebAssembly and check.
2017-08-09 19:04 GMT+07:00 Jukka Jylänki :
> This looks like a performance bug in the browser. It may be possible
> to reduce the compilation time, but without a test case it's n
This looks like a performance bug in the browser. It may be possible
to reduce the compilation time, but without a test case it's not
possible to know what might be wrong. Is the project public somewhere?
One known source of slow compilation times is if one has very large
switch-case statements wi
