Upgrade emscripten to 2.0.26+

[axic]

Keeping in line with regular upgrades, last we upgraded in 0.8.1 in #10747:

Update the soljson.js build to emscripten 2.0.12 and boost 1.75.0.

Emscripten is at 2.0.26 now, the interesting changes for us:
2.0.26:

• Undefined data symbols (in static executables) are no longer silently ignored at link time. The previous behaviour (which was to silently give all undefined data symbols address zero, which could lead to bugs) can be enabled by passing either -Wl,--allow-undefined or -Wl,--unresolved-symbols=ignore-all.
• The alignment of long double, which is a 128-bit floating-point value implemented in software, is reduced from 16 to 8. The lower alignment allows max_align_t to properly match the alignment we use for malloc, which is 8 (raising malloc's alignment to achieve correctness the other way would come with a performance regression). (Disable travis. #10072)

And a lot of other asyncify imporvements/changes, though we do not use that feature yet.

2.0.25:

• By default (unless EXIT_RUNTIME=1 is specified) emscripten programs running under node will no longer call process.exit() on exit(). Instead they will simply unwind the stack and return to the event loop, much like they do on the web. In many cases the node process will then exit naturally if there is nothing keeping the event loop going. Note for users of node + pthreads: Because of the way that threads are implemented under node multi-threaded programs now require EXIT_RUNTIME=1 (or call emscripten_force_exit) in order to actually bring down the process.
• Drop support for node versions older than v5.10.0. We now assume the existence of Buffer.from which was added in v5.10.0. If it turns out there is still a need to support these older node versions we can add a polyfil under LEGACY_VM_SUPPORT (SMTChecker: Loop is unrolled after it completes #14447).

2.0.24:

• CMake projects (those that either use emcmake or use Emscripten.cmake directly) are new configured to install (by default) directly into the emscripten sysroot. This means that running cmake --install (or running the install target, via make install for example) will install resources into the sysroot such that they can later be found and used by find_path, find_file, find_package, etc. Previously the default was to attempt to install into the host system (e.g /usr/local) which is almost always not desirable. Folks that were previously using CMAKE_INSTALL_PREFIX to build their own secondary sysroot may be able to simplify their build system by removing this completely and relying on the new default.
• Standalone wasm mode no longer does extra binaryen work during link. It used to remove unneeded imports, in hopes of avoiding nonstandard imports that could prevent running in WASI VMs, but that has not been needed any more. A minor side effect you might see from this is a larger wasm size in standalone mode when not optimizing (but optimized builds are unaffected). (Add --exclude option to cmdlineTests.sh #14338)

2.0.23:

• libcxxabi updated to llvm-12. (CLI and Standard JSON equivalence tests #14288)
• libcxx updated to llvm-12. (Experimental standard library #14249)
• compiler-rt updated to llvm-12. (Misspelling and terms inconsistencies #14280)

2.0.22:

• wasm-ld will now perform string tail merging in debug string sections as well as regular data sections. This behaviour can be be disabled with -Wl,-O0. This should significantly reduce the size of dwarf debug information in the wasm binary.

2.0.21:

• Options such as EXPORTED_FUNCTIONS that can take a response file containing list of symbols can now use a simple one-symbol-per-line format. This new format is much simpler and doesn't require commas between symbols, opening or closing braces, or any kind of escaping for special characters.
• The WebAssembly linker (wasm-ld) now performes string tail merging on any static string data in your program. This has long been part of the native ELF linker and should not be observable in well-behaved programs. This behavior can be disabled by passing -Wl,-O0.

2.0.19:

• When building with -s MAIN_MODULE emscripten will now error on undefined symbol by default. This matches the behvious of clang/gcc/msvc. This requires that your side modules be present on the command line. If you do not specify your side modules on the command line (either direcly or via RUNTIME_LINKED_LIBS) you may need to add -s WARN_ON_UNDEFINED_SYMBOLS=0 to avoid errors about symbol that are missing at link time (but present in your side modules provided at runtime). We hope that this case is not common and most users are building with side modules listed on the command line (Solc 0.8.18: Added optimization rule and(shl(X, Y), shl(X, Z)) => shl(X, and(Y, Z)) #14060).

2.0.18:

• EXTRA_EXPORTED_RUNTIME_METHODS is deprecated in favor of just using EXPORTED_RUNTIME_METHODS.

2.0.17:

• Use of closure compiler (--closure) is now supported when using dynamic linking (building with -s MAIN_MODULE) (Allow support for older boost and adjust docs #13880)
• Use LLVM's new pass manager by default, as LLVM does. This changes a bunch of things about how LLVM optimizes and inlines, so it may cause noticeable changes in compile times, code size, and speed, either for better or for worse. You can use the old pass manager (until LLVM removes it) by passing -flegacy-pass-manager (and -Wl,--lto-legacy-pass-manager when doing LTO) (note however that neither workaround affects the building of system libraries, unless you modify emscripten or build them manually). (How can the contract detect the mode of calling according to solidity docs? #13427)
• Binaryen now always inlines single-use functions. This should reduce code size and improve performance. If you prefer the old default, you can get that with -sBINARYEN_EXTRA_PASSES=--one-caller-inline-max-function-size=1 (Update the review checklist to address common external PR problems #13744).

2.0.16:

• Lists that are passed on the command line can now skip the opening an closing braces, allowing for simpler, more readable settings. e.g. -s EXPORTED_FUNCTIONS=foo,bar
• In MINIMAL_RUNTIME build mode, errno support will now be disabled by default due to the code size that it adds. (MINIMAL_RUNTIME=1 implies SUPPORT_ERRNO=0 by default) Pass -s SUPPORT_ERRNO=1 to enable errno support if necessary.

2.0.14:

• Clang now performs loop unrolling when targeting WebAssembly at -O2 and higher. It can be disabled using -fno-unroll-loops.

2.0.13:

• Emscripten now builds a complete sysroot inside the EM_CACHE directory. This includes the system headers which get copied into place there rather than adding a sequence of extra include directories.
• The system for linking native libraries on demand (based on the symbols present in input object files) has been removed. Libraries such as libgl, libal, and libhtml5 are now included on the link line by default unless -s AUTO_NATIVE_LIBRARIES=0 is used. This should not effect most builds in any way since wasm-ld ignores unreferenced library files. Only users of the --whole-archive linker flag (which is used when MAIN_MODULE=1 is set) should be effected.

[axic]

Probably we can also remove this workaround: https://github.com/ethereum/solidity/blob/develop/scripts/ci/build_emscripten.sh#L71-L74

[axic]

Emscripten is up at 2.0.31 now. Only build and bug fixes.

[axic]

@ekpyron did you had a chance to look at the changelog here? The highlighted parts look interesting.

[ekpyron]

I somehow missed that mention of mine... meanwhile it's 2.0.33, but no more exciting changes... but since this might interact with #12228 it may be a good time to look into this - sounds like it could fix the exit-from-node-issues etc.

[ekpyron]

It's driving me nuts that with each version the emscripten docker images change the directory in which they search for cmake files of dependencies...

[ekpyron]

I guess $(em-config CACHE)/sysroot will do it this time, but will need to rebuild everything to confirm.

[ekpyron]

Actually, I missed the 2.0.24 change:

• CMake projects (those that either use emcmake or use Emscripten.cmake directly) are new configured to install (by default) directly into the emscripten sysroot. This means that running cmake --install (or running the install target, via make install for example) will install resources into the sysroot such that they can later be found and used by find_path, find_file, find_package, etc. Previously the default was to attempt to install into the host system (e.g /usr/local) which is almost always not desirable. Folks that were previously using CMAKE_INSTALL_PREFIX to build their own secondary sysroot may be able to simplify their build system by removing this completely and relying on the new default.

So actually I can skip setting the directory altogether.

But still this 2.0.32 change breaks our build for now:

• Emscripten will now warn when linker-only flags are specified in compile-only (-c) mode. Just like with clang itself, this warning can be disabled using the flag: -Wno-unused-command-line-argument.

Might be nice to properly split the options instead of just disabling the warning.

[ekpyron]

Hm... boost doesn't seem to play nice with current emscripten so far...

[ekpyron]

I'm giving up for now. Seems like this is one of the times at which this update will be a huge hassle...

[axic]

Any chance going to something like 2.0.24 or anything getting us closer and merging the work you already did?

[ekpyron]

I can run some builds on the side, but my best guess would be that 2.0.23 is the culprit with

• libcxxabi updated to llvm-12. (CLI and Standard JSON equivalence tests #14288)
• libcxx updated to llvm-12. (Experimental standard library #14249)
• compiler-rt updated to llvm-12. (Misspelling and terms inconsistencies #14280)

The errors I'm getting seem to be some weird incompatibilities with the <complex> and <cmath> headers (among others) and boost...

[axic]

Even going to 2.0.22 would be nice as a first step.

[ekpyron]

I'm actually not sure if it's worth the time to file an issue with boost about their own emscripten toolset setup not working at all...

[ekpyron]

I may have found a solution - emscripten provides a weird set of compatibility headers and apparently installing boost in its sysroot causes the boost headers to include the wrong headers, but installing boost elsewhere might work. (Although then it's a bit of a hassle to have cmake find it again, but what can one do)