Phase 5 Windows: DLL + source-built tokenizer, on-device verified [draft, stacks on #6] - #7
Closed
NestorCanales wants to merge 8 commits into
Closed
Phase 5 Windows: DLL + source-built tokenizer, on-device verified [draft, stacks on #6]#7NestorCanales wants to merge 8 commits into
NestorCanales wants to merge 8 commits into
Conversation
… assets Adds windows-amd64 to assets/manifest.json: the official Microsoft ONNX Runtime DLL (onnxruntime-win-x64-1.26.0.zip, member-pinned) and our source-built libtokenizers.a. daulet/tokenizers ships no Windows prebuilt, so it is built from the v1.27.0 tag with the GNU Rust toolchain (must match MinGW gcc that CGo links with) and hosted in this repo's releases (tokenizers-1.27.0-windows-x64), SHA-256 pinned like every artifact. - assets_embed_windows.go: per-platform go:embed of onnxruntime.dll. - Makefile: extract .zip archives (unzip, else Windows System32 tar) so make assets works on Windows — tars stay the path for the others. - Documentation/windows-build.md: full build + artifact-provenance recipe (toolchain versions, the GNU-must-match-MinGW constraint, the libtokenizers_ffi.a -> libtokenizers.a rename in the v1.27.0 layout). Tokenizer lib compiled on Windows x64 (rustc 1.97.1 GNU, Go 1.26.5, MinGW gcc 16.1.0). App build + on-device verification run next on the PC. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ilt tokenizer The Windows libtokenizers.a (Rust std, GNU toolchain) references Nt*/Rtl*, Winsock and crypto syscalls that MinGW does not link by default, so the Windows `make build` failed with "undefined reference to NtCreateFile" etc. Makefile LINK_LIBS now appends -lntdll -lws2_32 -lbcrypt -luserenv -ladvapi32 -lkernel32 -lncrypt when GOOS=windows; empty on macOS/Linux (verified LINK_LIBS = -ltokenizers there), so those builds are unchanged. Observed and resolved during the first on-device Windows build; the integration test then linked and passed (cosine ordering 0.140 < 0.171 < 0.286, matching every other platform). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sqlite-vec's cgo bindings #include sqlite3.h / sqlite3ext.h. macOS (SDK) and Linux (system libsqlite3) supply those; Windows has neither, so the full `make build` failed with "sqlite3.h: No such file or directory" (after the tokenizer link was resolved). New Windows-only `winhdr` prerequisite copies the headers mattn/go-sqlite3 already bundles (its sqlite3-binding.h IS the amalgamation sqlite3.h) into build/winhdr and points CGO_CFLAGS there — guaranteeing they match the SQLite mattn compiles in, no download or vendor. macOS/Linux unchanged: WIN_PREREQ + CGO_EXTRA_CFLAGS expand empty there (verified LINK_LIBS=-ltokenizers, no winhdr prereq, CGO_CFLAGS=""). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…fied Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Windows GUI smoke (headless SSH couldn't open a window), full untagged test suite on Windows (watcher TestOnCreate presumably fails pre-PR#5, unverified), and the linux-amd64 on-device runtime smoke. Coverage gaps, not known defects — recorded so they survive the session. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…d, fix verified 3/3 on Windows Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…only defaultClaudeDesktopConfigPath hardcoded the macOS location (~/Library/Application Support/Claude/). On Windows the button therefore wrote a well-formed config to a path Claude Desktop never reads — and reported success. Found live during the Phase 5 Windows GUI smoke: the misplaced file existed at C:\Users\<u>\Library\Application Support\... while Claude Desktop (reading %APPDATA%\Claude\) fell back to manual filesystem browsing instead of the MCP tool. Now per-OS: windows → %APPDATA%\Claude\; darwin → unchanged; linux → $XDG_CONFIG_HOME/Claude or ~/.config/Claude. Stdlib runtime aliased as goruntime (wails runtime already owns the name in app.go). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Collaborator
Author
|
Consolidated into #2 (single reviewable branch per Bo's review-workflow preference) — all commits from this PR are now in |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Windows x64 support — the final Phase 5 platform. Stacks on #6 → #4 → #3 → #2; review in order. With this, the local model runs out-of-the-box, offline, on every platform the app ships.
Built and verified natively on a Windows PC, driven from the dev Mac over SSH (Tailscale).
Changes
assets/manifest.json—windows-amd64: official Microsoft ONNX Runtime DLL (onnxruntime-win-x64-1.26.0.zip, member-pinned) + our source-builtlibtokenizers.a.libtokenizers.asource-built — no upstream Windows prebuilt exists. Built fromdaulet/tokenizersv1.27.0 with the GNU Rust toolchain (must match MinGW gcc; MSVC yields an unlinkable.lib). Published astokenizers-1.27.0-windows-x64, SHA-256 pinned. (The v1.27.0 layout emitslibtokenizers_ffi.a, renamed to the canonicallibtokenizers.a.)assets_embed_windows.go— embedsonnxruntime.dll.Makefile— three Windows-only additions, all guarded byGOOS=windows(macOS/Linux verified unaffected):.ziparchive extraction inmake assets(unzip → Windowstar.exefallback).LINK_LIBSappends NT/Winsock/crypto syscall libs the Rust static lib needs (-lntdll -lws2_32 -lbcrypt -luserenv -ladvapi32 -lkernel32 -lncrypt) — MinGW doesn't link them by default.winhdrstep stagessqlite3.h/sqlite3ext.h(which sqlite-vec's cgo needs; Windows has no system copy) from the headers mattn/go-sqlite3 already bundles, version-matched.Documentation/windows-build.md— full build + provenance recipe. Epic updated with findings.Two Windows-only build gaps (found live, fixed permanently)
Both surfaced only on Windows and are now baked into the Makefile behind a
GOOS=windowsguard, so they self-resolve on the next Windows build and don't touch the other platforms:undefined reference to Nt*/Rtl*(Rust std syscalls).sqlite3.h: No such file— sqlite-vec needs the header the system provided on Mac/Linux.Verification (native Windows x64)
make assets— all four artifacts download + checksum-verify, incl..zipextraction and our published tokenizer release0.140 < 0.171 < 0.286, matching every platformmake build→agent-memory.exe(193 MB PE32+ GUI x86-64)windows-amd64-<fingerprint>/and answers an MCP search on a Mac-indexed DB ("how do I cook italian pasta" → carbonara-recipe.md) — cross-platform vector compatibility confirmed--network noneLinux/Intel runs already proved thatPhase 5 status
All four targets built & verified. Remaining: linux-amd64 runtime smoke (artifacts pinned, needs an x64 Linux box) + Phase 6 cleanup.
🤖 Generated with Claude Code