Dlink-enabled web export broken with emscripten 3.1.45 (last known working version: 3.1.39) #82865
Comments
|
Official templates are also built with In godotengine/godot-cpp#1247 (comment) @Faless had different results based on whether LTO was enabled. But this should have been solved in 4.2-dev6 by #82633. |
Hello, thanks for the response! I compiled with
Browser Console Log (`template_debug`)
Browser Console Log (`template_release`)
Browser Console Log (`template_debug`)
Browser Console Log (`template_release`)
Overall, the most concerning part for me is that it still can't run the sample project which doesn't contain any GDExtension usage at all. Edit: if needed, here's the source for my gdext test project: |
|
I can reproduce this with the godot chess example and the same commit of (57a6813), emcc version 3.1.45 |
|
Interesting observations @Esption . I decided to test the latest 4.1.x versions and (shiver me timbers!) they didn't seem to work either... at least with emsdk 3.1.45.
If I understood correctly, however, it seems that something somewhere is fundamentally broken in the Update: Without LTO on 4.1.1, it errors due to imports exceeding the 100k limit. Update: I added above that the test project does work in 4.1.1 when compiling with emsdk 3.1.18. So perhaps this is a problem with the recent emsdk versions? |
Yep, I can confirm also the current |
Faless
changed the title
|
Also please note that there seem to be a Firefox bug causing GDExtension not to work. |
|
Okay, I have bisected the problem to Emscripten 3.1.40 (v3.1.39 was the last working version on my tests). Others may want to confirm. On each test, while having checked out
Logs for the index.pck problem
|
|
I've also been testing various emscripten versions for a c++ gdextension project. The only version of emscripten I've found that compiles, loads, and correctly executes my c++ gdextension is 3.1.28. In my testing, emsdk versions up to 3.1.27 fail with I tested a number of emsdk versions between 3.1.18 and 3.1.46 before finding 3.1.28 worked (manual binary search). In all of my tests, I left my project source the same and built templates against Godot 4.2 dev 6 (57a6813) and godot-cpp current master (ef2f63a), compiling the web templates with |
|
Thank you very much for finding this @bobziuchkovski ! I can confirm that, while doing tests with the Rust GDExtension bindings ( So, to recap, when compiling with
I'm not sure if problem 2 (related more to actual GDExtension usage) is 100% on-topic for this issue though, perhaps it deserves a separate one. I'll leave this decision up to Godot maintainers. |
|
I'm also interested in knowing whether the GDExtension stuff should be considered separate. I've tracked down the upstream emscripten change that breaks GDExtension w/3.1.29+, but I don't want to clutter this issue if that should be discussed elsewhere. 🤷♂️ |
|
I think we can keep discussing the 3.1.29 regression in this issue. Having So the problems will only be solved once we have |
akien-mga
changed the title
|
Excellent. Then in that case, the 3.1.29 regression is caused by emscripten-core/emscripten#18382. In particular, this line. If you emsdk install/activate 3.1.29-3.1.33, commenting that line is enough to get GDExtension builds working. After 3.1.34, there's some additional restructuring in that file so that it's no longer a single line edit. However, I think ultimately it's still interplay with that |
|
@bobziuchkovski thank you very much for tracking this down. This appears to be indeed a problem on the Godot side then, we use a custom That is probably messing up with loading the extensions, now that's being used for loading dynamic libraries too. |
|
The remaining issue ( I can compile and successfully run my GDExtension project on emscripten 3.1.47 (latest stable) with that single commit reverted (using #83165). I'm still trying to make sense of how, exactly, that shared side module logic is failing with respect to godot, though. LInking with |
Faless
changed the title
|
There's a PR open in the emscripten-core repo that fixes this issue: emscripten-core/emscripten#19496. Hopefully that will land. I confirmed godot 4.2beta2 built against HEAD of emscripten works with the changes from emscripten-core/emscripten#19496 applied. |
|
For 4.2-beta3 and later I'm upgrading Emscripten from 3.1.18 (same version as used in 4.1 and earlier 4.2 builds) to 3.1.39, since it's the last known working version. We might stick to it for 4.2-stable. |
|
Just copying from the linked Emscripten issue: it appears the problem is fixed by PR emscripten-core/emscripten#19496 That PR is still being actively reviewed and worked on. |
Due to godotengine#82865, newer versions can't be used for dlink-enabled Web builds. This isn't a problem for CI which doesn't use dlink, but it's clearer for users if our CI version matches the one we use for official builds.
Due to godotengine#82865, newer versions can't be used for dlink-enabled Web builds. This isn't a problem for CI which doesn't use dlink, but it's clearer for users if our CI version matches the one we use for official builds. (cherry picked from commit 51aff13)
Due to godotengine#82865, newer versions can't be used for dlink-enabled Web builds. This isn't a problem for CI which doesn't use dlink, but it's clearer for users if our CI version matches the one we use for official builds.
|
As another point of reference, I get the same That's a build of master (4.3 dev) from a couple of months ago (start of March). With the official 4.3.dev5 template I get a more cryptic error, What I managed to figure out is that the wasm tables in the main thread and in a sub-thread are different. This index exists in the much bigger main-thread table, but not in the table of a sub-thread. Frustratingly, I can't get DWARF to work in Chrome, despite compiling with debug symbols (both the engine and the extension), so there isn't much more I can comprehend. PS. I also tried a |
|
A small update about my case. I confirmed the issue with https://github.com/godotengine/godot-cpp-template, and also confirmed that it works in 4.2 stable. 4.3 dev 6 is still broken, however a Dlink-enabled build of current master (5708a3a) actually exports! No changes to the project or the extension itself between runs. I haven't tried my actual project yet, but that's progress. So I guess some recent changes (from Adam?) fixed it, even though I still have no idea what the source of the problem was. Edit: The actual project works as well! It takes a while to load for some reason (the |
|
Good news everyone, emscripten-core/emscripten#19496 has been merged on the emscripten side. So, technically, 3.1.62 should be able to compile with Based on the release tempo, the 3.1.62 release should be imminent. |
|
Now that emscripten 3.1.62 has been released with the patch, I've recently tested the changes from #93143 (which appear to be available since 4.3-beta2) with godot-rust, and it's been a success! GDExtensions are working even on Firefox now - wonderful! I've tested both with the official 4.3-beta2 builds, as well as with web export templates built from source (commit 26d1577) with emscripten 3.1.62. The only problem I had, which I'll share in case others also face this, is that I didn't realize that, since Godot now uses the I eventually found out that Emscripten only generates those Perhaps that error could be improved, but I'm not sure if there's much for Godot to do here (maybe an issue could be raised on upstream?). Worth noting as well that With that out of the way, however, the (rather simple) GDExtensions I've tested seem to be working well on the web so far. 👍 |
|
This was indeed fixed in Emscripten 3.1.62, so closing. For the record, we're using 3.1.64 for official 4.3-rc/stable builds. |
Godot version
4.2.dev [57a6813]
System information
Godot v4.2.dev (57a6813) -
EndeavourOS #1 SMP PREEMPT_DYNAMIC Sat, 23 Sep 2023 22:55:13 +0000 - X11 - GLES3 (Compatibility) - llvmpipe (LLVM 16.0.6, 256 bits) () - AMD Ryzen 7 5700G with Radeon Graphics (8 Threads)Issue description
Hello,
I've been trying to debug WASM export with GDExtensions after the release of v4.2.dev6 (in a Linux OS), but I was using the official web export templates which don't appear to include the engine's debug symbols, so I decided to compile a web export template from source, checking out at what appears to be the latest commit to be included in v4.2.dev6 (57a6813). However, when I use a dlink-enabled web template compiled from source at that commit, any project fails to run in the web (any project, even a very trivial and just created one, will do), displaying on the web browser console the errors I show below instead of the game (for both Chromium and Firefox). Disabling
dlink_enabledworks - a trivial project runs -, but then, of course, I can't test GDExtension without that option enabled.Note that this occurs when compiling with or without debug symbols, with
template_debugortemplate_release, and only when compiling from source (the official web export templates, downloaded through the v4.2.dev6 editor, appeared to be fine).I've tested the export process throughout 3 different Linux distros (Debian 12 Podman container, EndeavourOS / Arch-based VM, NixOS bare metal), all with the same result. I've also tested compilation from source on both the Debian 12 container and on the EndeavourOS VM. I apologize in advance if I'm just missing some trivial flag or some other procedure (I'm mostly following the existing documentation).
The commands I've tried:
Compiling with the command below does, however, work (produces a functional web export template):
I've also compiled the editor at the same commit with:
(Using the official v4.2.dev6 editor didn't work either.)
I'm using emsdk 3.1.45:
The errors which appear on my Ungoogled Chromium v117 browser's console when trying to run the game (served on localhost with the official
serve.pyscript in the Godot repository) are the following (similar errors appear on Firefox v118.0.1):Steps to reproduce
git checkout --detach 57a6813bb8bc2417ddef1058d422a91f0c9f753cscons platform=linuxbsd target=editor(assuming Linux host)scons platform=web dlink_enabled=yes target=template_debug- you may have to rename the resultingbin/godot.web.template_debug.wasm32.dlink.zipfile tobin/web_dlink_debug.zip.TestProject.zipbelowbin/web_dlink_debug.zipfile (or place the file in the usual~/.local/share/godot/export_templates/4.2.dev/web_dlink_debug.ziplocation). Ensure "Extensions Support" is checked.platform/web/serve.pyscript (e.g.cdto where the project's main HTML file was exported to and runpython3 /path/to/godot/platform/web/serve.py -r "$(realpath .)").127.0.0.1:8060Minimal reproduction project
TestProject.zip
The text was updated successfully, but these errors were encountered: