Skip to content

v1.0.2

Latest
Latest

Choose a tag to compare

View all tags
@xushiwei xushiwei released this 06 Sep 15:11
· 18 commits to main since this release
v1.0.2
9317592
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Windows support

LLGo supports Windows natively: APIs declared with WINAPI/__stdcall are bound through the stdcall. namespace (only 386 has this distinct calling convention — amd64/arm64 use a unified native C ABI), and callbacks must be direct function references rather than capturing closures. Releases ship as four integrated archives split by architecture and toolchain (MSVC/MinGW for amd64/arm64), each bundling its own LLVM and C++ runtime dependencies; you only need to supply the matching native SDK/CRT and Clang environment (Visual Studio's C++ tooling for MSVC, or MSYS2 CLANG64/CLANGARM64 for MinGW).

Windows API

On Windows, bind APIs declared with WINAPI or __stdcall through the stdcall. namespace. The convention is distinct on 386; Windows amd64 and arm64 use their unified native C ABI. An explicitly decorated 386 name such as _MessageBoxW@16 is also accepted and is normalized to MessageBoxW on 64-bit targets.

//go:linkname MessageBoxW stdcall.MessageBoxW
func MessageBoxW(hwnd uintptr, text, caption *uint16, flags uint32) int32

//llgo:type stdcall
type Callback func(context uintptr) uintptr

stdcall. declarations and //llgo:type stdcall apply only to non-variadic function types. A native callback is one function pointer, so a Go callback must be a direct function reference; pass state through an explicit context pointer rather than a capturing closure.

MSVC vs. MinGW

The release workflow builds four integrated Windows archives: llgo<VERSION>.windows-{amd64,arm64}-{msvc,mingw}.tar.gz. Check the release assets for availability in each version. Add the extracted bin directory to PATH; the archives keep the same runtime, targets, and crosscompile/clang layout as Unix releases. The MSVC compiler links LLVM statically; MinGW archives include the native LLVM and C++ DLL dependencies beside llgo.exe.

Use the archive matching your native architecture and toolchain profile. Native programs still need the corresponding SDK/CRT, Clang, and dependencies described below: Visual Studio's C++ developer environment for MSVC, or MSYS2 CLANG64 (amd64) / CLANGARM64 (arm64) for MinGW. The bundled ESP Clang remains the upstream x64 Windows payload, including in ARM64 archives, and runs through Windows' x64 emulation there; llgo.exe itself is native ARM64 in those archives.

The recommended GNU-hosted setup is an MSYS2 CLANG64 shell. Install the LLVM 22 stack and LLGo's native dependencies, then provide the versioned pkg-config metadata used by the Go/C++ bindings:

pacman -S --needed \
  mingw-w64-clang-x86_64-{clang,llvm,llvm-tools,lld,lldb,compiler-rt,libc++,libunwind} \
  mingw-w64-clang-x86_64-{gc,libffi,libuv,openssl,cjson,sqlite3,zlib,pkgconf}
test "$(llvm-config --version | cut -d. -f1)" = 22
pc_dir="$MINGW_PREFIX/lib/pkgconfig"
mkdir -p "$pc_dir"
printf '%s\n' \
  'Name: LLVM 22' \
  'Description: LLVM 22 host compiler and linker flags' \
  "Version: $(llvm-config --version)" \
  "Cflags: $(llvm-config --cflags)" \
  "Libs: $(llvm-config --ldflags --libs all --system-libs)" \
  > "$pc_dir/llvm-22.pc"

The native MSVC CI profile uses LLVM's official 22.1.8 development archive for headers, libraries, Clang, LLD, and all code-generation backends. That archive does not contain LLDB, so the profile also extracts LLDB from the matching official win64 or woa64 installer. LLVM 22 has no official Win32 installer; the Windows 386 lane uses the LLVM 22.1.8-based llvm-mingw 20260616 builtins and qualifies the official x64 LLDB under WoW64. The complete pinned setup, checksums, and generated llvm-22.pc are in .github/actions/setup-deps/action.yml.

What's Changed

Full Changelog: v1.0.1...v1.0.2

Contributors

cpunion, xushiwei, and 2 other contributors
Assets 11
Loading