Support for Windows ARM64 builds in py4godot

[gr3vios]

…ot project.

Changes include:

• Adjustments to the build scripts to handle Windows ARM64 architecture.
• Dependencies updated to align with the requirements for this platform.

Known limitations:

• This implementation depends on Python 3.12.4 for Windows ARM64, which is not yet available.
• As a temporary workaround, Python 3.9.7 from jay0lee/CPython-Windows-ARM64 has been considered.

This work follows the same approach as the Linux ARM64 support and is a draft implementation. Feedback is welcome, especially regarding compatibility and potential improvements.

[gr3vios]

This file does not exist yet, the version is in process: astral-sh/python-build-standalone#387

[niklas2902]

Hey, thank you very much for investigating it. I finally got it working by using the interpreter from nuget. and uploading it to my repo here: prebuilt-windowsarm64

Like this, i needed to adapt download_file like this:

    if platform != "linux32" and platform != "linux64" and platform != "windowsarm64":
        url = f'https://github.com/indygreg/python-build-standalone/releases/download/20240726/{python_ver}+20240726-{platform_dict[platform]}.tar.gz'
        python_file = f'{python_files_dir}/{python_ver}-{platform_dict[platform]}.tar.gz'
    elif platform == "linux64":
        url = f'https://github.com/niklas2902/prebuild-python-linux64/releases/download/release-0.1/{python_ver}-linux64.zip'
        python_file = f'{python_files_dir}/{python_ver}-linux64.zip'
    elif platform == "windowsarm64":
        url = f'https://github.com/niklas2902/prebuilt-windowsarm64/releases/download/release-0.1/{python_ver}-windowsarm64.zip'
        python_file = f'{python_files_dir}/{python_ver}-windowsarm64.zip'
    else :
        url = f'https://github.com/niklas2902/prebuild-python-linux32/releases/download/release-0.1/{python_ver}-linux32.zip'
        python_file = f'{python_files_dir}/{python_ver}-linux32.zip'

[gr3vios]

@niklas2902 Thanks for the implementation details and the NuGet-based approach - that's a solid solution for the ARM64 Python dependency issue.

I've implemented your suggested download_file() modification and the MSVC ARM64 build changes. I went with a simpler approach for the MSVC configuration compared to your winarm64 branch - just the essential x64_arm64 targeting. Let me know if you'd prefer the more robust Visual Studio detection approach from your branch.

Also added the remaining pieces needed for complete Windows ARM64 support (library entries, cross-compilation config).

I merged with the latest master and resolved conflicts, but would appreciate validation of the conflict resolutions.

Ready for your review when convenient.

[niklas2902]

Hey, thank you very much for investigating it. I finally got it working by using the interpreter from nuget. and uploading it to my repo here: prebuilt-windowsarm64

Like this, i needed to adapt download_file like this:

    if platform != "linux32" and platform != "linux64" and platform != "windowsarm64":
        url = f'https://github.com/indygreg/python-build-standalone/releases/download/20240726/{python_ver}+20240726-{platform_dict[platform]}.tar.gz'
        python_file = f'{python_files_dir}/{python_ver}-{platform_dict[platform]}.tar.gz'
    elif platform == "linux64":
        url = f'https://github.com/niklas2902/prebuild-python-linux64/releases/download/release-0.1/{python_ver}-linux64.zip'
        python_file = f'{python_files_dir}/{python_ver}-linux64.zip'
    elif platform == "windowsarm64":
        url = f'https://github.com/niklas2902/prebuilt-windowsarm64/releases/download/release-0.1/{python_ver}-windowsarm64.zip'
        python_file = f'{python_files_dir}/{python_ver}-windowsarm64.zip'
    else :
        url = f'https://github.com/niklas2902/prebuild-python-linux32/releases/download/release-0.1/{python_ver}-linux32.zip'
        python_file = f'{python_files_dir}/{python_ver}-linux32.zip'

[niklas2902]

Thank you very much for your work and sorry for the late response.

It all looks, very good. I have finally managed to get a github action to work with windows arm64. During this, I also noticed, that I have to adapt my build.py like you can see here: https://github.com/niklas2902/py4godot/blob/winarm64/build.py, so that it enables msvc for windows arm

[gr3vios]

Hi @niklas2902!

I wanted to provide you with a comprehensive update on the Windows ARM64 implementation. After the initial development, I've spent extensive time testing the compiled plugin builds on actual ARM64 hardware, I've made significant progress but also I'm facing with maybe a runtime issue.

TL;DR

Started with complete failure (Error 126: Cannot load library) → discovered missing ARM64 dependencies and symbol export issues → created diagnostic tools to understand the problem → fixed library loading with main.def and dependency management → py4godot now successfully loads and initializes on Windows ARM64! Currently investigating why _ready() methods aren't executing (placeholder logic bug?) and working around path resolution requiring Godot exe in project directory.

The full history

When I first tried running py4godot on Windows ARM64, I was greeted with the dreaded "Error 126: Cannot load library." The plugin wouldn't even start - complete failure. After diving deep into the codebase and your NuGet-based Python approach, I realized we had two fundamental problems lurking beneath the surface.

I created a suite of diagnostic tools to understand what was going wrong:

• Built comprehensive dependency analyzers
• Created DLL loading testers using Python ctypes
• Developed automated project creators for testing

The investigation revealed the culprits:

• Missing ARM64 runtime libraries (msvcp140.dll, ucrtbase.dll)
• Symbol export failure - py4godot_init wasn't being exported from main.dll
• Path resolution issues in the library loading chain

After testing on ARM64 hardware(Qualcomm Adreno 8cx Gen 3). I implemented the fixes:

• The Symbol Export Fix: Created py4godot/godot_bindings/main.def and updated meson.build to properly export symbols:
  LIBRARY main
  EXPORTS
  py4godot_init

• Built an dependency management system that automatically finds and copies the required ARM64 runtime libraries.

• Enhanced Logging: Added detailed logging throughout pythonscript.cpp to track exactly what was happening during library loading.

And then... it worked!

[py4godot] Library loaded successfully. Looking for 'py4godot_init' symbol...
py4godot version loaded successfully!
Available items: ['Engine', 'Node2D', 'SignalArg', 'gdclass', 'signal', ...]

The plugin now successfully loads and initializes on Windows ARM64! No more Error 126! The Python interpreter starts, classes import correctly, and the basic infrastructure is fully functional. But here's where the story gets interesting... While celebrating the successful plugin loading, I noticed something odd. The _ready() methods in Python scripts weren't executing - print statements inside them never appeared.

Digging deeper, I discovered maybe a bug (not sure yet) in the placeholder instance logic:
// In PyScriptExtension.cpp:377
gd_instance->is_placeholder = !transfer_object.is_tool;

This maybe incorrectly marks all non-tool scripts as placeholders, and placeholders are blocked from calling lifecycle methods in instance.h:82-84. (again not sure at all..)

The Current State

What Works:

• Complete ARM64 compilation (1043 targets!)
• Plugin loading without any errors
• Python interpreter initialization
• Import system functional
• Basic py4godot infrastructure operational

What Needs Investigation:

• Script lifecycle methods need the placeholder logic fix
• Path resolution still requires Godot exe in project directory (investigating)

Known Limitations

• Path Resolution: Godot executable must be placed in project directory for correct DLL loading (not yet resolved)
• Script Execution: Requires placeholder logic fix for full functionality

Tools Created️

Throughout this journey, I created a toolkit that maybe will help to others devs:

• Developer tools (tools/arm64/) - Diagnostic suite for contributors
• User-Friendly Helpers (build_resources/plugin_tools/) - Simplified troubleshooting for end users
• Complete Documentation - Step-by-step guides and workflows (build_resources/README.md)

Thanks for your guidance throughout this process!

[niklas2902]

Hey,

Thanks so much for the extensive work you did. I'll look into it and see if I can figure out why the lifecycle methods aren't working. Normally, they should work when you start the game, but not in the editor. That's why we have this condition for the placeholder. So maybe there's still an issue with the Python interpreter.