0.3.3#92
Merged
takeshi-yoshimura merged 5 commits intoJul 7, 2026
Merged
Conversation
Importing the cpp extension previously required d3d12.dll and dxgi.dll to be resolvable at Windows loader time because the .pyd linked them statically, even though they are only needed once DirectStorage is initialized. Drop the d3d12/dxgi/dxguid/uuid/ole32 link libraries, load d3d12.dll and dxgi.dll with LoadLibraryExW(LOAD_LIBRARY_SEARCH_SYSTEM32) inside init_dstorage(), resolve D3D12CreateDevice/CreateDXGIFactory1 via GetProcAddress, and define the required COM IIDs locally so dxguid/uuid are not needed. ole32 was never referenced. Plain import of the extension no longer depends on DirectX runtime availability, matching how dstorage.dll was already handled. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Takeshi Yoshimura <tyos@jp.ibm.com>
The 0.3.3 release run failed on all win_amd64 wheels with "ImportError: DLL load failed while importing cpp: The specified module could not be found" while the same commit range built fine on 2026-06-04. Comparing the job logs showed the windows-latest image moved from windows-2025 to windows-2025-vs2026 between the runs (same OS build 10.0.26100), so the wheels are now compiled by a newer MSVC toolchain. The leading suspect is a new CRT satellite DLL dependency that is not installed on the image or on end-user machines, the same failure mode vcruntime140_1.dll and msvcp140_atomic_wait.dll caused when they were introduced. - Run delvewheel repair on Windows wheels so MSVC runtime dependencies are vendored into the wheel, as auditwheel already does for Linux. - Register <pkg>.libs via os.add_dll_directory in smoke_import_cpp.py: delvewheel normally patches the package __init__ to do this, but the smoke test bypasses __init__ on purpose. - Add tests/dump_pyd_imports.py (temporary, Windows-only): prints the .pyd import table and where each DLL resolves from, so the next failure names the missing DLL. Remove once the root cause is recorded in windows_runner_issue.md. - Fix the version bump missed in the first 0.3.3 attempt (pyproject still said 0.3.2). - windows_runner_issue.md documents the investigation and the verification plan before re-tagging 0.3.3. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Takeshi Yoshimura <tyos@jp.ibm.com>
A verification run on the windows-2025-vs2026 image confirmed the root cause of the 0.3.3 Windows wheel import failure: the image builds with MSVC toolset 14.51 (VS2026) while its installed VC redistributable is 14.40, so delvewheel warned it was vendoring an msvcp140.dll older than the toolset that built the .pyd. With delvewheel repair the smoke import passes, and d3d12.dll/dxgi.dll no longer appear in the import table. To close the remaining version gap, install the vc_redist.x64.exe that ships inside the image's own Visual Studio (located via vswhere) before building; it matches the build toolset by construction. Exit codes 1638 (same or newer already installed) and 3010 (success, reboot required) are treated as success, so the step stays harmless once the image catches up. Also improve the import diagnostic: label api-ms-*/ext-ms-* imports as loader-resolved API sets instead of falsely reporting them as missing, and report the MSVC runtime DLLs present in System32 with their file versions to pin down what the unrepaired wheel could not resolve. Remove windows_runner_issue.md; it was a temporary investigation note and its conclusions are recorded here. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Takeshi Yoshimura <tyos@jp.ibm.com>
The VC redist update step worked (System32 CRT DLLs are now 14.51.36247.0, matching the MSVC toolset), but delvewheel still vendored a stale 14.40 msvcp140.dll: its DLL search follows PATH order, and some other tool on the runner ships an older copy in a directory that comes before System32. Pass --add-path C:/Windows/System32 so the freshly updated copy takes precedence. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Takeshi Yoshimura <tyos@jp.ibm.com>
234a4f0 to
fe23e06
Compare
- README: ROCm is no longer nogds-only, drop "without GDS". - overview.md: document hipFile-based direct loading on ROCm >= 7.2 (added in foundation-model-stack#85) instead of claiming ROCm has no GDS equivalent, and reflect that the gds copier now falls back to the nogds path at runtime with a warning (foundation-model-stack#87) rather than failing to open files. - development.md: the Makefile target is test-vllm, not vllm. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Takeshi Yoshimura <tyos@jp.ibm.com>
daf6cc3
into
foundation-model-stack:main
13 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
windows-latest seems to be changed from before and it manifested potential problems in the win binary.
This contains fixes for windows build as well as the version string change.