Repository navigation
Provide an import .lib for Warp's .dll(s) on Windows #1888
Description
Currently a native C++ application that wants to use Warp's .dll files directly (e.g. to use APIC .wrp files without Python code) has to dynamically load them and resolve each symbol individually using GetProcAddress(). It's a significant amount of boilerplate code per such application, and it needs to be updated every time Warp's entry points change.
It would be greatly simplified by providing .lib import libraries which automatically load the .dll and resolve the symbols. Applications merely have to link against it and include Warp's corresponding header.
One caveat the users of these .libs must stay aware of is that mismatched .dll versions can cause the application not to launch, or crash, with little or no indication of what went wrong. That said, similar issues also exist on Linux and Darwin where one links directly with the .so or .dylib. The user must ensure to ship the same version of dynamic libraries the application linked against, and put them in the paths the OS searches first.
APIC is still an experimental API and will undergo changes in the near future before settling down. We're also considering providing backward or forward compatibility guarantees through stable API versioning and symbol querying mechanisms as the need arises, but this is out of scope for now.
Activity
Samyra312007 commentedon Sep 2, 2026
Respected Maintainer and Author, I would like to understand about this issue end to end and work on it. Is it open for contributors?
Decouple Windows link smoke test (NVIDIAGH-1888)
Constrain Cppcheck API macro (NVIDIAGH-1888)
Design Windows import libraries (NVIDIAGH-1888)
Expose native DLL imports (NVIDIAGH-1888)
Package Windows import libraries (NVIDIAGH-1888)
Test Windows import linking (NVIDIAGH-1888)
Document native Windows linking (NVIDIAGH-1888)
Complete native artifact contract (NVIDIAGH-1888)
Decouple Windows link smoke test (NVIDIAGH-1888)
Ship Windows Import Libraries (NVIDIAGH-1888)
Ship Windows Import Libraries (NVIDIAGH-1888)
Ship Windows Import Libraries (NVIDIAGH-1888)
Ship Windows Import Libraries (NVIDIAGH-1888)
Ship Windows Import Libraries (NVIDIAGH-1888)
Ship Windows Import Libraries (NVIDIAGH-1888)
shi-eric commentedon Sep 12, 2026
This is addressed by 4c281cf.
Windows wheels now ship
warp.libandwarp-clang.libalongside their DLLs, and native applications can includewarp.h,apic.h, and the newwarp_clang.hto link directly instead of resolving the covered entry points withGetProcAddress(). The native ABI remains experimental: headers, import libraries, DLLs, and APIC artifacts must come from the same Warp release. Closing this as completed.Public API behavior
warp.libandwarp-clang.libusing the declarations shipped in the wheel.warp-clangC ABI exposed bywarp_clang.his experimental and intentionally limited to the CPU-module functions required by standalone APIC consumers.Test coverage
tools/ci/windows_import_library_smokeadds thewindows_import_library_smokeCTest consumer, which links both libraries from an installed wheel and exercises initialization, version validation, CPU runtime binding, APIC state creation, and warp-clang entry points..github/workflows/ci.ymlruns the installed-wheel test on Windows x86-64 with CUDA 12 and CUDA 13 and on Windows ARM64 CPU. All three jobs passed for this commit.Behavioral verification
A targeted native-linking reproduction confirmed direct linking and execution against both libraries, matching native-library versions through the Python loader, rejection of an incomplete Windows wheel, and inclusion of both DLL/import-library pairs and their public headers in a complete wheel.
Support native Windows linking from wheels [NVIDIAGH-1888]