Release 5.0.7

[emscripten-bot]

With emscripten-releases revisions:
https://chromium.googlesource.com/emscripten-releases/+/6cd98e86d7749ff98b82b7f2ae78eb4f01942788 (LTO)
https://chromium.googlesource.com/emscripten-releases/+/8f07fe77a9ba5f112a6f0582c2920979582a8682 (asserts)

[sbc100]

@DoDoENT any idea why the the bazel builds seem to be failing here? Something about embuilder failing?

[kleisauke]

It looks like these lines:

emsdk/bazel/README.md

Line 77 in b8b37f9

"crtbegin",

emsdk/bazel/test_secondary_lto_cache/MODULE.bazel.lock

Line 186 in b8b37f9

"crtbegin",

emsdk/bazel/test_secondary_lto_cache/MODULE.bazel

Line 14 in b8b37f9

"crtbegin",

should be changed to crtbegin-mt instead (untested). See commit emscripten-core/emscripten@244759d.

[DoDoENT]

It looks like these lines:

emsdk/bazel/README.md

Line 77 in b8b37f9

"crtbegin",

emsdk/bazel/test_secondary_lto_cache/MODULE.bazel.lock

Line 186 in b8b37f9

"crtbegin",

emsdk/bazel/test_secondary_lto_cache/MODULE.bazel

Line 14 in b8b37f9

"crtbegin",

should be changed to crtbegin-mt instead (untested). See commit emscripten-core/emscripten@244759d.

A good point, but I wouldn't say that it needs to be replaced with crtbegin-mt, but instead completely removed. -mt versions are needed only when doing a build with threads enabled, and that does not seem to be tested at all - only basic and SIMD builds are tested.

However, removing it will probably cause problems downstream for users trying to use wasm-threads with Bazel (but may not if the original cache provided by emscripten is used). Ideally, CI should also be extended with a test that uses WASM threads and fixed so that it works.

[sbc100]

Thanks!

Kind of annoying that the failing phase (embuilder) doesn't seem to show any stdout or stderr when if fails. Is that fixable?

[DoDoENT]

Thanks!

Kind of annoying that the failing phase (embuilder) doesn't seem to show any stdout or stderr when if fails. Is that fixable?

I'm not sure, as I'm not a huge Bazel expert (maybe @fmeum or anyone else on the core Bazel team would know better). The problem here is that the error happens during "repository resolution time", i.e., emscripten invokes embuilder to prepare the bazel repository containing emscripten cache, and bazel generally expects that the only error that can happen here is a network error, so it doesn't have any rich error reporting mechanism (that I know of).

Btw., my PR that addresses this issue in a different way is now 6 months old and not yet merged, and it allows you to prepare the emscripten cache up front and simply download it at repository resolution phase, so bazel is not confused, the cache is fully hermetic, unlike the current approach which builds the cache locally on user's machine which doesn't play nicely with remote build and cache support Bazel is famous for.