Skip to content

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

Merged
absadiki merged 5 commits into
absadiki:mainfrom
BestSithInEU:agent/fix-cuda-13-iterator-build
Aug 22, 2026
Merged

fix: update whisper.cpp for CUDA 13.3#174
absadiki merged 5 commits into
absadiki:mainfrom
BestSithInEU:agent/fix-cuda-13-iterator-build

Conversation

@BestSithInEU

Copy link
Copy Markdown
Contributor

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
Contributor 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.

@BestSithInEU

Copy link
Copy Markdown
Contributor Author

@absadiki Thanks! I addressed both remaining items.

For Windows, the failure was caused by skipping the project custom repair, so whisper.dll was not available to delvewheel. I pushed commit 2c36c55 with a cleaner fix that removes NO_REPAIR entirely: setup.py now runs the custom DLL-aware repair only on Windows, while Linux and macOS use the default cibuildwheel repair. The workflow also disables the second cibuildwheel repair on Windows to avoid repairing the wheel twice.

I also downloaded the actual CPython 3.14 manylinux x86_64 artifact from run 32434425532 and tested it in a fresh virtual environment. The native extension imported successfully, the tiny.en-q5_1 model loaded, and end-to-end transcription of whisper.cpp samples/jfk.wav returned the expected sentence.

The new workflows are currently marked action_required with no jobs started. Could you please approve the pending Actions runs so the Windows runner can verify the updated repair path?

Wheels run: https://github.com/absadiki/pywhispercpp/actions/runs/32475696561

@absadiki
absadiki marked this pull request as ready for review August 22, 2026 00:21
@absadiki

Copy link
Copy Markdown
Owner

Awesome, all the CI checks are now passing!
Thanks a lot @BestSithInEU for fixing this and for the contribution :)

@absadiki
absadiki merged commit f7bf621 into absadiki:main Aug 22, 2026
24 checks passed
@BestSithInEU
BestSithInEU deleted the agent/fix-cuda-13-iterator-build branch August 22, 2026 02:29
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