Build Failure: ExecuTorch QNN Backend on Windows (Host/MSVC)

[carrycooldude]

🐛 Describe the bug

Build Failure: ExecuTorch QNN Backend on Windows (Host/MSVC)

Summary

I am attempting to build the ExecuTorch QNN backend on a Windows on Arm machine (targeting x86_64 host or generic Windows host) to perform model export and quantization. The build fails persistently due to multiple Windows-incompatibility issues, including reliance on POSIX APIs (dlfcn.h, mkdir), MSVC intrinsic conflicts in llvmMathExtras.h, and macro pollution from <windows.h> (conflicting with QNN SDK and std::complex).

Environment

• Host OS: Windows 11 (running on Arm64 / Snapdragon X Elite)
• Target: Windows x64 (via emulation) or generic Windows.
• Compiler: MSVC 19.4x (Visual Studio 2022)
• ExecuTorch Version: (Current main/recent)
• QNN SDK Version: v2.42.0.251225
• Python: 3.10

Reproduction Steps

1. Clone ExecuTorch and install dependencies.
2. Set QNN_SDK_ROOT to the Windows QNN SDK path.
3. Run CMake configuration for the QNN backend:

   cmake -S . -B build-x86 `
     -DEXECUTORCH_BUILD_QNN=ON `
     -DQNN_SDK_ROOT="C:/path/to/qnn/sdk" `
     -DEXECUTORCH_BUILD_KERNELS_QUANTIZED=ON

4. Run Build: cmake --build build-x86 --target install

Observed Errors & Analysis

1. Missing POSIX APIs (dlfcn.h, mkdir)

The QNN backend source code directly includes <dlfcn.h> and uses dlopen, dlsym, dlclose, and mkdir. These are not available on Windows MSVC.

• Files:
  • backends/qualcomm/runtime/SharedBuffer.cpp
  • backends/qualcomm/runtime/Utils.cpp (mkdir usage)
  • backends/qualcomm/runtime/backends/QnnImplementation.h
  • backends/qualcomm/runtime/backends/QnnSysImplementation.cpp
• Impact: Compiler errors Cannot open include file: 'dlfcn.h' and undefined identifier mkdir.

2. MSVC Intrinsic Conflicts (llvmMathExtras.h)

runtime/core/portable_type/c10/c10/util/llvmMathExtras.h has a manual extern "C" block declaring MSVC intrinsics (_BitScanForward, etc.) to avoid including <intrin.h>.

• Issue: When <windows.h> is inevitably included (to patch the missing POSIX APIs), it pulls in <intrin.h> (or related headers) which conflict with the manual extern "C" declarations.
• Error: error C2375: '_BitScanForward': redefinition; different linkage

3. Macro Pollution from <windows.h>

To fix the POSIX issues, we attempted to add shims using <windows.h> (LoadLibrary, GetProcAddress). However, <windows.h> defines macros like interface, min, max, and complex (if not careful).

• Conflict 1: interface macro conflicts with QNN SDK headers (QnnSystemInterface.h), causing syntax errors.
• Conflict 2: complex macro (from some C-compatibility headers pulled by Windows or SDK) conflicts with std::complex in C++ standard headers.
• Error: error C2061: syntax error: identifier '_C_double_complex' and error C1003: error count exceeds 100.

4. C++ Standard & Designated Initializers

The code uses designated initializers (e.g., .version = ... in structs), which is a C++20 feature.

• Issue: Configuring with CMAKE_CXX_STANDARD 20 to support this causes breakages in other dependencies (e.g., flatbuffers or specific MSVC STL headers) that aren't fully ready for strict C++20 or have regressions. Downgrading to C++17 breaks the designated initializers.

Partial Fixes Attempted

I attempted to verify if "simple" patches could fix this, but the cascade of errors suggests deep incompatibility:

1. POSIX Shims: Implemented dlopen -> LoadLibraryA wrappers.
2. NOMINMAX & WIN32_LEAN_AND_MEAN: Added to suppress min/max and reduce header bloat.
3. #undef interface: Required to make QNN SDK headers parseable.
4. llvmMathExtras.h Patch: Forced use of generic C++ implementations for bit counting to bypass MSVC intrinsic conflicts.

Request

Is full Windows build support for the QNN Backend (host side) planned? If not, could we get guidance on how to perform the QNN export/compilation step on Windows without building the full backend from source (e.g., strictly relying on the .whl or a purely Python-based flow)?

Versions

Build Issue while installing executorch for Qualcomm AI Backend on WIndows

cc @cccclai @winskuo-quic @shewu-quic @haowhsu-quic @DannyYuyang-quic @cbilgin

[carrycooldude]

pytorch/ao#2919

[haowhsu-quic]

Hi, we are currently working on native Windows support. Will reply on this thread once the flow is ready for testing.
Add @zhaoxul-qti for awareness.