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:
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.
Summary
Building CodexMonitor on Windows with the MSVC toolchain fails in
whisper-rs-sysduring 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
x86_64-pc-windows-msvcC:\Program Files\LLVM\binLIBCLANG_PATHset correctlygccinPATHError
Build fails in
whisper-rs-syswith errors like:Similar failures also occur for:
_G_fpos64_t_IO_FILEObservations
_G_fpos_t,_G_fpos64_t,_IO_FILE) are glibc/GNU-specific, not MSVC / Windows CRT types.bindgenis generating Linux/glibc bindings during a Windows build, or the bundled bindings were generated from a glibc environment and are being reused on MSVC.whisper-rsversions, including:whisper-rs = 0.12.0whisper-rs = 0.16.0which suggests the pre-generated bindings are also not MSVC-compatible.
Dependency resolution seen
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
whisper-rs/whisper-rs-sysversion combination for Windows?Possible directions