-s WASM=0 -s LEGACY_VM_SUPPORT=1 results in JSC_CONSTANT_REASSIGNED_VALUE_ERROR warning during linking #20810
Comments
|
https://emscripten.org/docs/tools_reference/emcc.html tells me
so, the only difference should be whitespace in JavaScript. How can removed whitespace result in |
…ipten#20810> but always using -g1. The warning with emscripten 3.1.50 sounds very dangerous, and since it is apparently caused by removing whitespace, additional whitespace is a small price to pay for correctness. git-svn-id: https://source.openmpt.org/svn/openmpt/trunk/OpenMPT@19943 56274372-70c3-4bfc-bfc3-4c3a0b034d27
[Fix] build: Makefile: Emscripten: Work-around <emscripten-core/emscripten#20810> but always using -g1. The warning with emscripten 3.1.50 sounds very dangerous, and since it is apparently caused by removing whitespace, additional whitespace is a small price to pay for correctness. ........ git-svn-id: https://source.openmpt.org/svn/openmpt/branches/OpenMPT-1.29@19946 56274372-70c3-4bfc-bfc3-4c3a0b034d27
[Fix] build: Makefile: Emscripten: Work-around <emscripten-core/emscripten#20810> but always using -g1. The warning with emscripten 3.1.50 sounds very dangerous, and since it is apparently caused by removing whitespace, additional whitespace is a small price to pay for correctness. ........ git-svn-id: https://source.openmpt.org/svn/openmpt/branches/OpenMPT-1.30@19945 56274372-70c3-4bfc-bfc3-4c3a0b034d27
[Fix] build: Makefile: Emscripten: Work-around <emscripten-core/emscripten#20810> but always using -g1. The warning with emscripten 3.1.50 sounds very dangerous, and since it is apparently caused by removing whitespace, additional whitespace is a small price to pay for correctness. ........ git-svn-id: https://source.openmpt.org/svn/openmpt/branches/OpenMPT-1.31@19944 56274372-70c3-4bfc-bfc3-4c3a0b034d27
Hmm, that is unexpected as we didn't make any significant changes I can think of to WASM=0 mode. I suggest that you bisect to find where this broke, that might be the fastest way to make progress here: https://emscripten.org/docs/contributing/developers_guide.html#bisecting |
|
|
I think perhaps the changes in #20700 meant that we now run closure compiler in a slightly different mode when transpiling. This means that most likely this closure warning was always there but closure was not being run. The fact that building withiout @manxorist can you double check by explictly adding The quick fix for this is to simply ignore the warning using |
Edit: I had tried with |
|
Sorry, ignore the last comment. 3.1.49 with |
|
The problem is actually way worse. Note that originally I had set |
|
It this Hopefully we can create a new closure test when we fix this issue. |
That's with 3.1.50 and it happens with any of |
But it doesn't happen with 3.1.49? I wonder if there is some way I can repro this locally to help me debug? Can you share your full link command line? From the settings you shared it looks like you are using |
Also happens with 3.1.49 if I pass
I have not yet found the time to provide a minimal reproducer. It may take me some days or weeks to find the time.
That's correct.
I think because some user requested us to do that. However looking at the output we are getting and diffing it against not providing that option, I doubt it is actually doing anything useful in our case?! I am by no means fluent in JavaScript though. However, I doubt we want to use |
|
Yes, I was going to suggest that you drop |
|
Could you maybe share the contents of |
So maybe this is wrong. But it worked for the last 7 years with I guess a related question from my side would why there always appears to exist a hard-coded The diff between setting |
This is what the Setting |
I think what you have written is valid and as you say has always been valid in the past. However, I think this is likely never been valid when using closure.. and we recently started using closure in a different way to perform transpilation which is why this only effecting you now. See #20700. |
Yeah, but then I cannot trivially run the resulting "binary" any more because it very fundamentally behaves completely differently from any other C++ target platform on the planet. Should I write additional JavaScript just to make the C++ program behave like the C++ program that I have actually written, to be able to run it via node.js? I guess I could set
Yeah, that's certainly confusing, I agree :). But Can you maybe explain why there always appears to be a variable named
So, how am I supposed to use Maybe I am confused about the details here, but why did it work when |
I think the problem is that declaring
I believe what happened here is that |
Within the module code
|
And So, why does I think what I want here is basically the "namespace" wrapping, but not the promise/function indirection. Or maybe I want the modularized function getting called implicitly, or something like that. |
Indeed
In the past we had an additional option called You can think of the current options as being more like |
Yeah, making that the default sounds like a great idea, as it would best match the traditional C/C++ model. Having multiple instances as an optional feature would be nice to have (i.e. simulating multiple Unix-like processes in a single web page, or something like that), but I think the most common use case is probably instantiating a single set of WASM or JS libraries and driving them from the page (or from C main()). |
|
As a matter of fact, I am currently building with So for now, this appears to be a work-around for me, at least for getting a clean build. It feels very fragile nonetheless, as any minor change in closure or how it is run with that particular combination of options is likely to break things again. |
|
|
|
I am now testing replacing the |
Uhm, well, sorry, I was wrong. I am still seeing |
Two symptoms of the same problem I imagine. The problem being the transpilation now requires code that is closure compatible, whereas is didn't before #20700 |
…ilds and use inline EM_ASM() instead, as this is more compatible with closure. See <emscripten-core/emscripten#20810 (comment)> and <emscripten-core/emscripten#20810 (comment)>. git-svn-id: https://source.openmpt.org/svn/openmpt/trunk/OpenMPT@19964 56274372-70c3-4bfc-bfc3-4c3a0b034d27
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See emscripten-core#20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to closure-compiler with `SIMPLE_OPTIMIZATIONS`. However this had the negative side effect that all input need to be free of closure compiler warnings, and this turned out not to be practical for all users. See #20810 for more on this When selecting a transpilation tool use I also evaluated `swx` (written in rust) and `esbuild` (written in go). `esbuild` was rejected because the simply don't support ES5 (evanw/esbuild#297). `swx` was rejected because it almost doubled the side of our `node_modules` directory by adding two 50mb binary files.
|
Thanks. I have tested current tot, and it appears to work without any work-around or warning for all cases I care about. My tests also pass. |
-s WASM=0 -s LEGACY_VM_SUPPORT=1with emscripten 3.1.50 results in the following warning when linking:(I cut away the 100kB of minified javascript)
Building with
-g1as suggested in the output makes the problem go away.It does not happen with either
-s WASM=2or-s LEGACY_VM_SUPPORT=0. It also did not happen with emscripten 3.1.49, so this is a regression.The other
LDFLAGSused in this particular build are-Oz -flto -s ALLOW_MEMORY_GROWTH=1 -s DISABLE_EXCEPTION_CATCHING=0 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s ERROR_ON_MISSING_LIBRARIES=1 -s EXPORT_NAME="'libopenmpt'" -s EXPORTED_FUNCTIONS="['_malloc','_free']"You can reproduce the problem by building https://github.com/OpenMPT/openmpt/tree/e5a90920223b0648be01b3f2ad917f9f4a375f85 with
make CONFIG=emscripten EMSCRIPTEN_TARGET=js VERBOSE=1 TEST=1 ONLY_TEST=1(on Linux, I have no idea if our build system works correctly on macOS).Edit: I added
-g1unconditionally as a work-around in a later commit, so it is mandatory to use the precise commit that I linked to reproduce the issue.The text was updated successfully, but these errors were encountered: