Godot 4.3.x github action builds failing

Skeir

Github action builds failing on Windows editor and template

i have been attempting to build the spine runtimes for the godot editor and templates for the past few months, ever since godot 4.3 came out. i have tried deleting my old fork and making a new one from the official spine github. it builds everything fine on godot 4.2 and previous versions, but only the windows build seems to be broken on godot 4.3 builds. i have done EVERYTHING i can to try building locally, but i just can't. i heavily prefer having my exported projects encrypted with a PCK key, and this so far has been the best way for me to do it.

steps:

make a fork from the official spine-runtimes github
in spine-godot-v4.yml in the /workflows directory, add this line at the bottom of the env: section
SCRIPT_AES256_ENCRYPTION_KEY: ${{ secrets.PCK_KEY }}
in your repository settings, go to Secrets and Variables, then Actions and create a new repository secret called PCK_KEY. you can test with a real 256-bit AES key if you want, or just some random value
once the changes are committed and pushed, wait for github actions to complete
check if windows builds for godot 4.3 were succesful

Runtime information

i'm currently using the latest spine runtime version 4.2

(if images aren't working)
4.3 windows editor log:
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\mutex(37): error C3861: '_Mtx_init_in_situ': identifier not found C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\mutex(536): error C3861: '_Cnd_init_in_situ': identifier not found C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\condition_variable(56): error C3861: '_Cnd_init_in_situ': identifier not found scons: *** [thirdparty\thorvg\src\loaders\svg\tvgSvgLoader.windows.editor.x86_64.obj] Error 2 scons: building terminated because of errors. [Time elapsed: 00:07:56.21] Error: Process completed with exit code 2.

4.3 template log:
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\mutex(37): error C3861: '_Mtx_init_in_situ': identifier not found C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\mutex(536): error C3861: '_Cnd_init_in_situ': identifier not found C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\condition_variable(56): error C3861: '_Cnd_init_in_situ': identifier not found scons: *** [thirdparty\thorvg\src\loaders\svg\tvgSvgLoader.windows.template_release.x86_64.obj] Error 2 scons: building terminated because of errors. [Time elapsed: 00:06:48.48] Error: Process completed with exit code 2.

Mario

Seems to be an issue in thorvg. Does building Godot 4.3 from the Godot repository work on your machine? We are not modifying thorvg or anything else in any way in the copy of the upstream Godot source tree. Our GitHub Action also compiles as it should on GitHub's Windows build servers. Hard to tell what's going on. My guess is that something in your Visual Studio setup is incorrect.

Try building vanilla Godot and post the full log output.

Skeir

Mario

i accidentally built Godot 4.4 from the latest commit on the master branch from the Godot repo (woops) however it did successfully build. i also tried to run the spine Github Action again, and got the same errors and results for only windows builds.

here's my vanilla Godot scons build logs:

godot-windows-build-log.txt

141kB

(i tbh just copied that from the console, i have no idea where else to get the logs as no file was generated)

Mario

We are now getting the same error on GitHub Actions. I have no idea why. I can compile everything on a local Windows machine just fine as well. It looks like a similar issue with mutex.h happened on GH Actions and Windows runners earlier this year:

actions/runner-images10020

I'm a bit out of ideas how to approach this issue, other than excluding thorvg from the build for now. I commented on this closed issue as well. The issue is not deterministic. The same code + build system setup works fine most of the time, but fails sometimes.

achzart

// build with spine as an internal godot module

git clone godotengine/godot.git
git clone EsotericSoftware/spine-runtimes.git

mkdir godot/modules/spine-godot
cp -r spine-runtimes/spine-godot/spine_godot/* godot/modules/spine-godot
cp -r spine-runtimes/spine-cpp/spine-cpp/ godot/modules/spine-godot

// edit godot/modules/spine_godot/SCscub to point to the new include paths
env.Append(CPPPATH=["./spine-cpp/include"])
env_spine_runtime.Append(CPPPATH=["./spine-cpp/include"])
env_spine_runtime.add_source_files(env.modules_sources, "./spine-cpp/src/spine/*.cpp")

// edit godot/modules/spine_godot/SpineAnimationTrack.cpp line 40
-- #include "godot/editor/editor_node.h"
++ #include "editor/editor_node.h"

// in the same file edit line 188 to 190
//Replace:
for (int i = 0; i < animation_libraries.size(); i++) {
animation_player->remove_animation_library(animation_libraries);
}
//With:
for (List<StringName>::Element *elem = animation_libraries.front(); elem; elem = elem->next()) {
animation_player->remove_animation_library(elem->get());
}

// edit godot/modules/spine_godot/SpineSprite.cpp line 56
-- #include "editor/editor_plugin.h"
++ #include "editor/plugins/editor_plugin.h"

// build engine normally for your platform

Mario

These lines do not match the latest code in the spine-runtimes repository 4.2 branch. I also do not see how they could fix an issue with thorvg?

Mario

Godot found a fix for thorvg:
godotengine/godot95861

I've applied this to our build as well. Here's hoping this finally fixes it.
EsotericSoftware/spine-runtimesactions/runs/12011961064/job/33482111790

Mario

I think I finally fixed this issue.
EsotericSoftware/spine-runtimesactions/runs/12014046660

If this build goes through, everything is good.

Nate

Loading Image
It's a Christmas miracle! 🥳

Mario

This has finally been resolved, using the nuclear option (patching thorvg ourselves, badly).

Future Godot 4.3 releases should include the fix, so we won't have to apply our hack to make this work on GitHub runners.

Skeir

woohoo! i was watching it be solved in realtime. building with github actions is typically a cleaner solution for me