Building for HTML5 stopped working for emsdk 2.0.18+

[2shady4u]

While exporting for HTML5 works adequately by using emsdk version 2.0.17, the following versions don't seem to work properly: 2.0.18 2.0.19 2.0.20

I'll investigate some more...

[2shady4u]

This issue might've been fixed by https://github.com/godotengine/godot/pull/48320

[akien-mga]

What does "not working properly" mean exactly? https://github.com/godotengine/godot/pull/48320 fixes an issue which outright prevents compiling Godot (linking fails).

[2shady4u]

@akien-mga Sorry for being unclear. I do think the issues might be related, but I'm unsure whether the issue is due to errors in godot-cpp or due to errors in the main Godot repository? Here are two examples of the GDNative example project deployed on Github Actions, one of them uses Emscripten v2.0.17 and the other one uses v2.0.18.

v2.0.17

Everything works fine for this version...

Minimal reproduction repository:

https://github.com/2shady4u/godot-cpp-emscripten-v2.0.17

Deployed HTML5 build:

https://2shady4u.github.io/godot-cpp-emscripten-v2.0.17/

v2.0.18

Using this version of Emscripten (or higher) doesn't work and creates following crash:

Minimal reproduction repository:

https://github.com/2shady4u/godot-cpp-emscripten-v2.0.18

Deployed HTML5 build:

https://2shady4u.github.io/godot-cpp-emscripten-v2.0.18/

[Faless]

Just tested with 2.0.20 and it does break with current Godot 3.3.1 stable release, but seems to work fine when the engine itself gets compiled with emcc 2.0.20 too.

I'm guessing they changed something in the linking metadata that breaks it. I don't think we can fix this. We'll probably have to fix the emcc version after all, given it breaks every 2 versions...

[object71]

I built today with the latest version of emcc 2.0.21. My setup builds using CMake where godot-cpp is added as a subdirectory along with my main project.

I found out that the only way for everything to work properly is to compile my GDNative code as an executable producing a wasm file instead of a shared library file.

I am not familiar enough with SCons but if there is an option to compile a wasm (without just changing the name of the shared lib to have a wasm extension) try with that. Also could you compile with "-s ASSERTIONS=1" so that error are displayed?

[Faless]

@object71 did you use it with the official 3.3.1 release? Or did you build the export template too with that emscripten version?

[object71]

@Faless I used the official 3.3.1 release and the official template. I even have a template repo for this - check it out: https://github.com/object71/GDNativeCosmos

On cmake configure it will also download official godot from the site into the godot folder. Then just cmake build for the current platform and for web (check the README for web).

[object71]

My mistake. I wasn't compiling with 2.0.21. I was using another installed version today. Yeah 21 doesn't work

[object71]

Seems that there should be a fix in Godot 3.3.2 - https://github.com/godotengine/godot/pull/48831

[2shady4u]

I'll update my test repositories to use Godot 3.3.2 and I'll see what happens when using latest Emscripten :D !

[2shady4u]

@object71 and @Faless I've updated all my test repositories (v2.0.17, v2.0.18 and latest) to the latest version of Godot (3.3.2). The 2.0.18 and latest Emscripten versions still do not work...

Here's the link to the repository using the latest version of Emscripten: https://github.com/2shady4u/godot-cpp-emscripten-latest

[Rubonnek]

I just stumbled on this linking issue myself with v2.0.24, but the linking actually works -- you have to clear your emscripten cache after updating emscripten.

According to a warning from the Arch Linux packagers:

You may need to manually clear your emscripten cache as clang may not link
the new library versions with cached data properly. Use this command:
$ emcc --clear-cache
You may also need to delete ~/.emscripten if emscripten complains about old paths
or executables not found.

And this was the issue for me.

[2shady4u]

@Rubonnek I'm building the plugin on Github Actions which basically spawns a new Linux instance every time I build. I don't think anything cache related is saved in-between runs so this can't be the problem imo.

Regardless I'm testing it right now... we'll see

EDIT: It didn't work 😭

[object71]

After a discussion thread in the main godot repo the short answer is - use the version that godot templates are exported with. For the current stable versions the used emscripten is 2.0.15 and for 3.4 it will be 2.0.25

If later version of emscripten is required - export templates can be built manually (check the documentation).

I think this issue can be closed at this point.

[extrawurst]

Would be great to point to where this can be looked up in the future for new godot releases? The emc version used that is

[Faless]

@extrawurst see https://github.com/godotengine/godot/pull/51832#issuecomment-902014057

[2shady4u]

It doesn't seem like the https://github.com/godotengine/build-containers-repository is up-to-date with 3.4. An alternative way to find out the correct Emscripten version is the javascript_build.yml-file as found in the main Godot repository:

https://github.com/godotengine/godot/blob/master/.github/workflows/javascript_builds.yml

Thus, for the latest master (4.0), the correct version of Emscripten is 2.0.27 (which might change in the future).

@object71 I would propose to keep this issue open until this version requirement is added to the README.md. Unless it would be better to make a separate issue that explicitly requests this to be added to the docs?

[akien-mga]

It doesn't seem like the godotengine/build-containers-repository is up-to-date with 3.4.

It is up to date: https://github.com/godotengine/build-containers/blob/main/Dockerfile.javascript#L6-L7

That's the versions used for 3.4 and 3.5 for now, as well as pre-alpha builds of 4.0.

Thus, for the latest master (4.0), the correct version of Emscripten is 2.0.27 (which might change in the future).

That's mostly arbitrary and we can move to a newer version after testing. We support a fairly wide range of Emscripten versions (Mono builds still use 1.39.9 because Mono itself doesn't support newer versions), the only risk is that sometimes they remove something in Emscripten which breaks Godot build until we work it around.

But yeah, pinning the Emscripten version across the Godot repositories makes sense, at least for production builds. For CI, it's actually useful to test the latest to see stuff break, though it's best done manually (pinning the version and updating it once in a while).