Issue Station
Sign In
Tools hereToolbox

pytorch - 💡(How to fix) Fix [Windows] clang-cl does not export inherited constructors of c10::Error subclasses, causing LNK2019 [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

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#181892•Fetched 2026-04-30 06:17:54
View on GitHub
Comments
0
Participants
1
Timeline
101
Reactions
0
Author
jeffdailyjeffdaily
Participants
jeffdailyjeffdaily
Timeline (top)
mentioned ×37subscribed ×37unsubscribed ×19labeled ×6

On Windows, when PyTorch is built with clang-cl, the constructors of c10::Error subclasses declared via using Error::Error; (and similar using Base::Base; patterns) are not emitted into c10.dll's export table. Any DLL or extension that does not link statically against c10 and tries to throw one of these errors (directly, or indirectly via macros such as TORCH_CHECK_VALUE / TORCH_CHECK_NOT_IMPLEMENTED) fails to link with:

error LNK2019: unresolved external symbol
  __declspec(dllimport) public: __cdecl c10::ValueError::ValueError(
      struct c10::SourceLocation,
      class std::basic_string<...>)

This is an instance of the upstream clang-cl bug https://github.com/llvm/llvm-project/issues/162640 — clang-cl does not emit dllexport symbols for constructors inherited via using Base::Base;, while MSVC does.

You can confirm by running dumpbin /exports c10.dll | findstr ValueError on a clang-cl build of PyTorch — the constructor symbols are absent from the export table.

Error Message

error LNK2019: unresolved external symbol __declspec(dllimport) public: __cdecl c10::ValueError::ValueError( struct c10::SourceLocation, class std::basic_string<...>)

Root Cause

On Windows, when PyTorch is built with clang-cl, the constructors of c10::Error subclasses declared via using Error::Error; (and similar using Base::Base; patterns) are not emitted into c10.dll's export table. Any DLL or extension that does not link statically against c10 and tries to throw one of these errors (directly, or indirectly via macros such as TORCH_CHECK_VALUE / TORCH_CHECK_NOT_IMPLEMENTED) fails to link with:

error LNK2019: unresolved external symbol
  __declspec(dllimport) public: __cdecl c10::ValueError::ValueError(
      struct c10::SourceLocation,
      class std::basic_string<...>)

This is an instance of the upstream clang-cl bug https://github.com/llvm/llvm-project/issues/162640 — clang-cl does not emit dllexport symbols for constructors inherited via using Base::Base;, while MSVC does.

You can confirm by running dumpbin /exports c10.dll | findstr ValueError on a clang-cl build of PyTorch — the constructor symbols are absent from the export table.

Fix Action

Fix

For each affected class, add an explicit constructor declaration in c10/util/Exception.h and a matching definition in c10/util/Logging.cpp (co-located with the existing Error::Error(SourceLocation, std::string) definition that already lives there). The definition just delegates to the base-class constructor, so there is no behavior change on any platform — it simply forces the compiler to emit an exported symbol.

Code Example

error LNK2019: unresolved external symbol
  __declspec(dllimport) public: __cdecl c10::ValueError::ValueError(
      struct c10::SourceLocation,
      class std::basic_string<...>)

---

python test/test_autograd.py TestAutograd.test_multi_grad_all_hooks
RAW_BUFFERClick to expand / collapse

Summary

On Windows, when PyTorch is built with clang-cl, the constructors of c10::Error subclasses declared via using Error::Error; (and similar using Base::Base; patterns) are not emitted into c10.dll's export table. Any DLL or extension that does not link statically against c10 and tries to throw one of these errors (directly, or indirectly via macros such as TORCH_CHECK_VALUE / TORCH_CHECK_NOT_IMPLEMENTED) fails to link with:

error LNK2019: unresolved external symbol
  __declspec(dllimport) public: __cdecl c10::ValueError::ValueError(
      struct c10::SourceLocation,
      class std::basic_string<...>)

This is an instance of the upstream clang-cl bug https://github.com/llvm/llvm-project/issues/162640 — clang-cl does not emit dllexport symbols for constructors inherited via using Base::Base;, while MSVC does.

You can confirm by running dumpbin /exports c10.dll | findstr ValueError on a clang-cl build of PyTorch — the constructor symbols are absent from the export table.

Reproducer

On Windows with PyTorch built using clang-cl (e.g. ROCm/HIP via TheRock):

python test/test_autograd.py TestAutograd.test_multi_grad_all_hooks

The test JIT-builds an inline C++ extension that links against c10.lib / torch_cpu.lib. Without an explicit definition, the link fails with LNK2019 on c10::ValueError::ValueError (referenced from c10::ivalue::Future::ensureIsSubsetOfDevices) and c10::NotImplementedError::NotImplementedError (referenced from torch::dynamo::autograd::CompiledNodeArgs::collect).

Affected classes

Every class in c10/util/Exception.h that gets its constructors via a using ...::...; declaration is affected, even if a particular symbol hasn't been observed as missing yet (it just means no caller outside of c10.dll happens to use it today). Concretely:

Direct subclasses of Error:

  • ErrorAlwaysShowCppStacktrace
  • IndexError
  • ValueError (partially fixed in #175340)
  • TypeError
  • NotImplementedError (partially fixed in #175340)
  • BufferError
  • EnforceFiniteError
  • OnnxfiBackendSystemError
  • LinAlgError
  • OutOfMemoryError
  • SyntaxError
  • DistError

Subclasses further down the chain:

  • DistBackendError, DistStoreError, DistNetworkError (inherit from DistError)
  • DistQueueEmptyError (inherits from DistStoreError)

AcceleratorError already declares an explicit constructor and is not affected.

Fix

For each affected class, add an explicit constructor declaration in c10/util/Exception.h and a matching definition in c10/util/Logging.cpp (co-located with the existing Error::Error(SourceLocation, std::string) definition that already lives there). The definition just delegates to the base-class constructor, so there is no behavior change on any platform — it simply forces the compiler to emit an exported symbol.

Related

extent analysis

TL;DR

Add explicit constructor declarations and definitions for affected classes in c10/util/Exception.h and c10/util/Logging.cpp to force the compiler to emit exported symbols.

Guidance

  • Identify all classes in c10/util/Exception.h that inherit constructors via using...::...; declarations and are missing exported symbols.
  • For each affected class, add an explicit constructor declaration in c10/util/Exception.h.
  • Add a matching definition in c10/util/Logging.cpp that delegates to the base-class constructor.
  • Verify the fix by running dumpbin /exports c10.dll | findstr <ErrorClass> and checking that the constructor symbols are present in the export table.

Example

// In c10/util/Exception.h
class ValueError : public Error {
public:
    using Error::Error; // existing declaration
    ValueError(SourceLocation loc, std::string msg) : Error(loc, std::move(msg)) {} // new explicit declaration
};

// In c10/util/Logging.cpp
ValueError::ValueError(SourceLocation loc, std::string msg) : Error(loc, std::move(msg)) {} // new definition

Notes

This fix is specific to the clang-cl compiler on Windows and is a workaround for the upstream bug https://github.com/llvm/llvm-project/issues/162640. The changes do not affect the behavior on other platforms.

Recommendation

Apply the workaround by adding explicit constructor declarations and definitions for affected classes, as this is a specific and targeted fix for the identified issue.

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…
#autograd error#model save/load#optimization#mixed precision#training loop

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

pytorch - 💡(How to fix) Fix [Windows] clang-cl does not export inherited constructors of c10::Error subclasses, causing LNK2019 [1 participants]