pytorch - ✅(Solved) Fix [Windows] Build failure in LazyNVRTC.cpp: 'uselocale' identifier not found (MSVC) [2 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
pytorch/pytorch#181154Fetched 2026-04-23 07:22:21
View on GitHub
Comments
1
Participants
1
Timeline
123
Reactions
0
Author
Participants
Timeline (top)
subscribed ×72mentioned ×39labeled ×7added_to_project_v2 ×1

Error Message

Error: C:\actions-runner_work\pytorch\pytorch\aten\src\ATen\cuda\detail\LazyNVRTC.cpp(155): error C3861: 'uselocale': identifier not found C:\actions-runner_work\pytorch\pytorch\aten\src\ATen\cuda\detail\LazyNVRTC.cpp(158): error C2065: 'locale_t': undeclared identifier

Root Cause

Potential Root cause:

PR fix notes

PR #180569: Workaround for nvrtcCompileProgram changing locale in CUDA < 12.6.2

Description (problem / solution / changelog)

There is a bug in CUDA 11.7 until CUDA 12.6.2 which changes the current thread locale when calling nvrtcCompileProgram. See e.g. https://stackoverflow.com/questions/74044994 This also includes the encoding used by Python by default for e.g. subsequent invocations of subprocess calls. When the user environment is now set to e.g. UTF-8 and changed by CUDA (to ASCII/ANSI_X3.4-1968) Python will fail to decode UTF-8 output from programs invoked. This happens e.g. in test_torch which calls from scipy import stats which runs lscpu and errors with something like

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 96: ordinal not in range(128)

Fix by wrapping the nvrtcCompileProgram saving and restoring the thread locale.

See previous PR #121822

Changed files

  • aten/src/ATen/cuda/detail/LazyNVRTC.cpp (modified, +31/-0)
  • aten/src/ATen/cuda/nvrtc_stub/ATenNVRTC.h (modified, +4/-0)

PR #181110: Workaround for nvrtcCompileProgram changing locale

Description (problem / solution / changelog)

There is a bug in CUDA 11.7 until CUDA 12.6.2 which changes the current thread locale when calling nvrtcCompileProgram. See e.g. https://stackoverflow.com/questions/74044994 This also includes the encoding used by Python by default for e.g. subsequent invocations of subprocess calls. When the user environment is now set to e.g. UTF-8 and changed by CUDA (to ASCII/ANSI_X3.4-1968) Python will fail to decode UTF-8 output from programs invoked. This happens e.g. in test_torch which calls from scipy import stats which runs lscpu and errors with something like

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 96: ordinal not in range(128)

Fix by wrapping the nvrtcCompileProgram saving and restoring the thread locale.

Includes fix for the warning reported by @ZainRizvi https://github.com/pytorch/pytorch/pull/180569#issuecomment-4291371807

Changed files

  • aten/src/ATen/cuda/detail/LazyNVRTC.cpp (modified, +33/-0)
  • aten/src/ATen/cuda/nvrtc_stub/ATenNVRTC.h (modified, +4/-0)

Code Example

C:\actions-runner\_work\pytorch\pytorch\aten\src\ATen\cuda\detail\LazyNVRTC.cpp(155): error C3861: 'uselocale': identifier not found                                                                    
  C:\actions-runner\_work\pytorch\pytorch\aten\src\ATen\cuda\detail\LazyNVRTC.cpp(158): error C2065: 'locale_t': undeclared identifier
RAW_BUFFERClick to expand / collapse

🐛 Describe the bug

Windows binary wheel builds previously are failing to compile due to use of POSIX-only functions uselocale and locale_t in aten/src/ATen/cuda/detail/LazyNVRTC.cpp, which are not available in MSVC.
Error:


  C:\actions-runner\_work\pytorch\pytorch\aten\src\ATen\cuda\detail\LazyNVRTC.cpp(155): error C3861: 'uselocale': identifier not found                                                                    
  C:\actions-runner\_work\pytorch\pytorch\aten\src\ATen\cuda\detail\LazyNVRTC.cpp(158): error C2065: 'locale_t': undeclared identifier

Affected configurations:

  • windows-binary-wheel / wheel-py3_11-cuda12_6-build
  • windows-binary-wheel / wheel-py3_11-cuda12_8-build (and likely all CUDA versions on Windows)

CI links:

Issue seen in https://github.com/pytorch/pytorch/pull/180569 which got reverted. However still seeing the same issue in the CI run in the new PR https://github.com/pytorch/pytorch/pull/181110

Potential Root cause:

uselocale and locale_t are POSIX extensions not supported by MSVC. The code in LazyNVRTC.cpp needs to be guarded with #ifndef _WIN32 or replaced with the MSVC equivalent (_create_locale / _free_locale).

cc @malfet @seemethere @peterjc123 @mszhanyi @skyline75489 @nbcsm @iremyux @Blackhex @ptrblck @msaroufim @eqy @jerryzh168 @nWEIdia @pytorch/pytorch-dev-infra @Flamefire @ZainRizvi

Versions

nightly cuda 12.6 builds

extent analysis

TL;DR

The most likely fix is to guard the POSIX-only functions uselocale and locale_t in LazyNVRTC.cpp with #ifndef _WIN32 or replace them with MSVC equivalents.

Guidance

  • Verify that the error messages C3861: 'uselocale': identifier not found and C2065: 'locale_t': undeclared identifier are related to the use of POSIX-only functions in LazyNVRTC.cpp.
  • Check if the code in LazyNVRTC.cpp can be modified to use MSVC equivalents _create_locale and _free_locale instead of uselocale and locale_t.
  • Consider adding a preprocessor directive #ifndef _WIN32 to guard the POSIX-only functions and prevent them from being compiled on Windows.
  • Review the CI links provided to ensure that the issue is reproducible and related to the suspected root cause.

Example

#ifndef _WIN32
// use uselocale and locale_t
#else
// use _create_locale and _free_locale
#endif

Notes

The fix may require modifications to the LazyNVRTC.cpp file and may need to be reviewed and tested thoroughly to ensure that it does not introduce any new issues.

Recommendation

Apply a workaround by guarding the POSIX-only functions with #ifndef _WIN32 or replacing them with MSVC equivalents, as the root cause is related to the use of unsupported functions in MSVC.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING