Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
#599 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Quiet
Tech stack
rust

Research direction

Start by reproducing the failure for x86_64-pc-windows-msvc and inspect whisper-rs-sys binding generation, bundled bindings, and the resolved whisper-rs versions. Compare the behavior with WHISPER_DONT_GENERATE_BINDINGS=1 and the documented Windows build path. Done means establishing a supported Windows build approach and documenting or implementing the required compatibility change.

Written by the indexing model from the issue text.

Description

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.
Dominant language
TypeScript
Stars
4.3k
Forks
416
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Dimillian/CodexMonitor

All issues in Dimillian/CodexMonitor

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.