Windows build failure: whisper-rs-sys bindgen generates glibc-specific types under MSVC

Summary

Building CodexMonitor on Windows with the MSVC toolchain fails in whisper-rs-sys during binding generation / validation.

The generated or bundled bindings appear to assume glibc/GNU types and layouts, which are not valid for x86_64-pc-windows-msvc.

This blocks local Windows development from source.

Environment

• OS: Windows 11
• Rust: 1.95.0
• Target: x86_64-pc-windows-msvc
• LLVM/clang installed at C:\Program Files\LLVM\bin
• LIBCLANG_PATH set correctly
• No gcc in PATH
• Using MSVC toolchain, not MinGW/MSYS2

Error

Build fails in whisper-rs-sys with errors like:

error[E0080]: attempt to compute `12_usize - 16_usize`, which would overflow
["Size of _G_fpos_t"][::std::mem::size_of::<_G_fpos_t>() - 16usize];

Similar failures also occur for:

• _G_fpos64_t
• _IO_FILE

Observations

• These types (_G_fpos_t, _G_fpos64_t, _IO_FILE) are glibc/GNU-specific, not MSVC / Windows CRT types.
• That suggests bindgen is generating Linux/glibc bindings during a Windows build, or the bundled bindings were generated from a glibc environment and are being reused on MSVC.
• The issue reproduces across multiple whisper-rs versions, including:
  • whisper-rs = 0.12.0
  • whisper-rs = 0.16.0
• It also still happens when setting:

WHISPER_DONT_GENERATE_BINDINGS=1

which suggests the pre-generated bindings are also not MSVC-compatible.

Dependency resolution seen

whisper-rs v0.14.3 (git)
└── whisper-rs-sys v0.13.0

Why this matters

CodexMonitor documents Windows source builds and ships Windows artifacts, but this failure makes it unclear how Windows builds are expected to work for contributors using the standard MSVC Rust target.

Questions

• How is CodexMonitor successfully producing a Windows MSI today?
• Are bindings pre-generated in a Windows-safe way somewhere else?
• Is a specific toolchain required here (MSYS2 / MinGW vs MSVC)?
• Is there a known-good whisper-rs / whisper-rs-sys version combination for Windows?
• Should Windows builds disable dictation / whisper by default until bindings are known to be portable?

Possible directions

• Avoid generating bindings from glibc headers on Windows/MSVC.
• Ship Windows/MSVC-compatible pre-generated bindings.
• Gate dictation / whisper behind target-specific features.
• Document the exact supported Windows toolchain and dependency expectations.