Skip to content

fix: update whisper.cpp for CUDA 13.3 - #174

Draft
BestSithInEU wants to merge 2 commits into
absadiki:mainfrom
BestSithInEU:agent/fix-cuda-13-iterator-build
Draft

fix: update whisper.cpp for CUDA 13.3#174
BestSithInEU wants to merge 2 commits into
absadiki:mainfrom
BestSithInEU:agent/fix-cuda-13-iterator-build

Conversation

@BestSithInEU

Copy link
Copy Markdown

What changed

  • Update the whisper.cpp submodule from v1.8.4 to v1.8.5.

Cause

CUDA 13.3 uses newer CCCL headers that no longer pull in <cuda/iterator> transitively through <cub/cub.cuh>. The pinned v1.8.4 sources call cuda::make_strided_iterator and cuda::make_counting_iterator without including that header, causing CUDA builds to fail in argsort.cu and top-k.cu. This was also reported in CrispASR#262.

Whisper.cpp v1.8.5 is the first patch release containing the explicit iterator includes in both files.

Impact

Restores pywhispercpp source builds with CUDA 13.3 while keeping the dependency on a tagged whisper.cpp patch release.

Validation

  • Built a wheel with GGML_CUDA=1 CMAKE_BUILD_PARALLEL_LEVEL=8 pip wheel --no-deps --no-cache-dir .
  • Build completed successfully with CUDA 13.3.1 on an NVIDIA RTX 4080
  • Produced pywhispercpp-1.5.1.dev1+gf3b74543d.d20260818-cp314-cp314-linux_x86_64.whl

@absadiki

Copy link
Copy Markdown
Owner

Thanks @BestSithInEU for the PR!
I noticed that the Wheels CI is currently failing.
Do you know what is causing these failures? Are they related to the whisper.cpp v1.8.5 update ?
Could you please take a look when you get a chance?
Thanks!

@BestSithInEU

BestSithInEU commented Aug 21, 2026

Copy link
Copy Markdown
Author

Thanks for flagging this @absadiki. I investigated all three failing wheel jobs. They are not caused by the whisper.cpp v1.8.5 update: the Linux x86_64, Linux ARM, and Windows jobs all compile successfully and produce wheels containing libwhisper 1.8.5.

The failures happen afterward in wheel repair:

  • Linux/ARM: the setup.py repairwheel step uses an auditwheel version that rejects the musllinux_1_2 platform tag.
  • Windows: cibuildwheel 4 now runs delvewheel by default after setup.py has already repaired the wheel, so the second repair produces no output wheel.

The previous passing run used cibuildwheel 3.4.1, while this run picked up unpinned cibuildwheel 4.2.0. Current main also enables the setup.py repair step on Linux.

I additionally rebuilt this PR from a fresh checkout with CUDA 13.3.73 and Python 3.14 on an RTX 4080. The wheel compiled, installed, detected the RTX 4080, loaded tiny.en on CUDA, and completed inference.

A minimal packaging fix is to set NO_REPAIR=1 in CIBW_ENVIRONMENT so cibuildwheel alone owns the platform repair stage. Since that is separate from the CUDA 13 source fix, I have kept this PR scoped to the whisper.cpp update. I can submit the packaging change separately if preferred.

@absadiki

Copy link
Copy Markdown
Owner

Thanks @BestSithInEU for the detailed investigation and for testing this so thoroughly. I really appreciate it :)

It's totally fine to include the packaging fix in this PR as well, so I can merge everything in one go once all the CI checks are passing.

The Linux and ARM wheel issues seem to be resolved, but the Windows wheel is still failing. Could you please take a look at that one as well?

Also, I'm not 100% sure, but if I remember correctly, setting NO_REPAIR=1 might cause the packaged Linux wheels to not work correctly. I think we'll need to test the resulting artifacts on Linux to make sure the change doesn't introduce another issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants