Skip to content

0.3.3#92

Merged
takeshi-yoshimura merged 5 commits into
foundation-model-stack:mainfrom
takeshi-yoshimura:tyos/fix-win-build
Jul 7, 2026
Merged

0.3.3#92
takeshi-yoshimura merged 5 commits into
foundation-model-stack:mainfrom
takeshi-yoshimura:tyos/fix-win-build

Conversation

@takeshi-yoshimura

Copy link
Copy Markdown
Collaborator

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.

takeshi-yoshimura and others added 4 commits July 7, 2026 15:33
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>
- 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>
@takeshi-yoshimura takeshi-yoshimura merged commit daf6cc3 into foundation-model-stack:main Jul 7, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant