Platform support

Linux x86_64 is the developed and verified platform; everything on this site is exercised there. macOS and Windows are expected to work for the core system (upstream Godot ships both, including library builds) but have not been built or tested from this fork yet. This page lists what carries over, what needs porting, and what is Linux-only by design.

Component matrix

Component	Linux	macOS	Windows
Engine + bridge module (all transports' dispatch)	✅ verified	✅ expected — portable Godot code	✅ expected
library_type=shared_library + guido_* C API	✅ verified	✅ expected (upstream libgodot_macos.mm, "library" supported)	✅ expected (libgodot_windows.cpp; GUIDO_API already uses dllexport)
stdio transport, logs→stderr	✅ verified	✅ expected (UnixTerminalLogger inherits the redirect)	✅ expected (WindowsTerminalLogger patched to honor it; CRLF handled — engine strips \r inbound, SDKs trim)
In-process transport	✅ verified	⚠️ works, main-thread rule (below)	✅ expected
Unix socket / --spawn	✅	✅ (POSIX)	❌ use --bridge-pipe (implemented, untested) or TCP
TCP + token	✅	✅	✅
--no-project boot	✅ verified	✅ expected (RD builds default to their own renderer)	✅ expected
Dual-use executable .so	✅ (glibc x86_64 only)	❌ by design — macOS cannot exec dylibs	❌ by design — DLLs aren't executable
Self-extract stub (misc/selfextract)	✅ verified	❌ needs port + codesign story	⚠️ needs a Win32 port (overlay on PE is fine)
Bun single binary (embed .so → extract → dlopen)	✅ verified	✅ expected (bun --compile re-signs its own output; extracted dylib keeps its ad-hoc link-time signature)	✅ expected
merge_static_lib.sh (ar -M)	✅	❌ use libtool -static	❌ use lib.exe (MSVC exports only dllexport symbols anyway)
Version-script export trimming	✅	❌ use -exported_symbols_list (cosmetic — dlsym works regardless)	n/a (dllexport is already the allowlist)
Language examples	✅ all seven verified	⚠️ mostly portable (below)	⚠️ C/Go examples use dlfcn — need LoadLibrary variants

Known porting caveats

1. macOS: UI must run on the process main thread

AppKit requires windowing on thread 0. This constrains which thread may call guido_start()/guido_iteration():

• Bun pumps on the process main thread, which satisfies the rule.
• Python's InprocTransport pumps on a background thread. That works on Linux and works headless anywhere, but windowed macOS needs the pump on the main thread: run the pump loop there and move app logic to a worker, or use the default spawned mode, which has no such constraint (the engine process owns its own main thread).
• Compiled hosts can call the API from main().

2. Packaging is per-platform

The 32 MB self-extracting trick is Linux-only as written (/proc/self/exe, execv, ELF trailer). On Windows the same design ports cleanly (PE overlays are the classic installer pattern; GetModuleFileNameW + CreateProcessW). On macOS, appending to a signed Mach-O invalidates its signature — single-file distribution there should rely on --pack=none plus the platform's own compression (.dmg/.zip, which macOS transparently handles) or a re-signing step after packing.

3. Library naming and build scripts

build_ui_library.sh / build_ui_runtime.sh are platform=linuxbsd scripts. macOS/Windows builds use the same scons options with platform=macos / platform=windows (drop the GNU-specific ccflags/linkflags), and produce libgodot.macos....dylib / godot.windows....dll — SDK path detection and the bundler currently hardcode the Linux name and need the small lookup table.

What is portable by construction

• The protocol and everything above guido_send/guido_recv — pure strings.
• The FFI surfaces used by the bindings: bun:ffi, Python ctypes, Rust libloading, Zig std.DynLib (with -lc), Nim std/dynlib all handle .so/.dylib/.dll natively. Only the raw-dlfcn examples (C, Go's cgo shim) are POSIX-specific.
• The engine-side transports: dispatch is transport-agnostic; per-platform code is confined to the accept/read/write adapters that already exist (including the Windows named pipe).

Suggested porting order

1. Windows sidecar (stdio): build platform=windows with the same module set; stdio + the logger redirect are already in place. Verify --bridge-pipe while there.
2. macOS library: platform=macos library_type=shared_library; wire the main-thread pump note into the Python SDK (main-thread mode).
3. Windows library: exports already correct via dllexport; test bun:ffi LoadLibrary path.
4. Packaging stubs last; they are size optimizations, not functionality.