feat(compat.openblas): Windows support (import-lib + runtime DLL) + Windows CI - #55
Merged
Conversation
…ime DLL
Adds Windows to compat.openblas. OpenBLAS has no upstream Make path for the
MSVC-ABI Clang mcpp links with, so Windows uses the prebuilt x64 zip: link the
MSVC import lib (lib/libopenblas.lib) and ship the runtime DLL
(bin/libopenblas.dll) beside the consumer's .exe. mcpp >= 0.0.73 stages a
dependency's [runtime] library_dirs *.dll next to the executable (PE has no
RPATH), so the consumer launches standalone.
Recipe:
* xpm.windows: OpenBLAS-0.3.33-x64.zip (GLOBAL OpenMathLib GitHub; CN gitcode
mcpp-res/openblas, uploaded + GET-verified byte-equal). Unpacks to
bin/ lib/ include/ (no wrapper dir).
* mcpp ldflags are now per-OS (the synthesized-manifest parser APPENDS
ldflags, so a global -lopenblas would wrongly reach the Windows link):
linux/macosx link the static -lopenblas; windows links -llibopenblas
(clang MSVC maps it to libopenblas.lib).
* mcpp.windows: [runtime] library_dirs=["bin"] (DLL deploy) + a
generated_files anchor TU (no Make build on Windows). install() returns
immediately on windows; linux/macosx keep the source build.
CI (Phase D): smoke_compat_portable.sh gains a Windows-only OpenBLAS
build-AND-run — cblas_dgemm must produce [19 22; 43 50], and the produced .exe
is launched DIRECTLY from a neutral CWD so a clean exit proves the DLL was
actually deployed beside it (not merely found via mcpp run's PATH prepend).
MCPP_VERSION pinned 0.0.68 -> 0.0.73 (the release carrying DLL deployment).
See mcpp .agents/docs/2026-06-29-windows-runtime-dll-deployment-and-openblas.md.
The Phase D direct-launch assertion ran the .exe found by `find target` (a
path relative to the project dir) after `cd /`, so it resolved to a
nonexistent path ("No such file or directory") and failed even though the
build linked the import lib, deployed bin/libopenblas.dll beside the .exe (the
DLL-presence check passed), and `mcpp run` succeeded. Absolutise the exe path
(exedir via pwd + basename) before the neutral-CWD launch.
Sunrisepeak
added a commit
that referenced
this pull request
Sep 11, 2026
* feat(compat.vulkan): 1.4.357.3 ships the Vulkan loader on Windows A Windows program that links `vulkan-1.lib` needs `vulkan-1.dll` at process start, and that DLL is not part of Windows. It arrives with a GPU driver, with LunarG's Vulkan Runtime redistributable, or beside an application. A machine without a driver has none, and the program dies before `main` with 0xC0000135 (STATUS_DLL_NOT_FOUND). Measured on GitHub's `windows-2022` image (#387 probe, run 34569282837): `vulkan`, `eui-neo-vulkan` and `vulkan-hpp-module` all fail that way, while images that happen to carry a driver pass. WHAT CHANGES compat.vulkan 1.4.357.3 windows artifact adds bin/vulkan-1.dll and LICENSE.txt; mcpp.windows.runtime gains library_dirs = { "bin" } khronos.vulkan-hpp 1.4.357.1 same headers, pin -> compat.vulkan 1.4.357.3 compat.eui-neo 0.5.9.1 upstream 0.5.9 unchanged, `vulkan` feature pin -> compat.vulkan 1.4.357.3 members vulkan 1.4.357.3, vulkan-hpp-module 1.4.357.1, eui-neo-vulkan 0.5.9.1 tests/examples/vulkan on Windows, asserts the mapped vulkan-1.dll lives in the executable's own directory THE MECHANISM ALREADY EXISTS AND IS NOT NEW HERE. mcpp copies every *.dll under a dependency's `runtime.library_dirs` beside the executable it builds (mcpp #185, v0.0.73); `compat.openblas` has shipped `bin/libopenblas.dll` this way on Windows CI since mcpp-index #55. Two properties this change leans on were measured locally with mcpp 2026.9.11.2 rather than assumed: * transitive -- app -> mid -> dep(bin/vulkan-1.dll): the DLL lands beside `app`. `vulkan-hpp-module` and `eui-neo-vulkan` reach compat.vulkan only transitively. * test binaries -- `mcpp test` places it beside the test executable too. `mcpp pack` needs nothing further: its PE closure always searches the executable's own directory ("whatever the build staged beside it ... is by definition part of what it runs with"), and `vulkan-1.dll` is not in its system-DLL allow-list, so the deployed copy is what a packed program carries. THE ARTIFACT (xlings-res/vulkan-import 1.4.357.3, sha256 8118f1bd...12f5) lib/vulkan-1.lib byte-identical to 1.4.357.1's vulkan-1.def upstream `loader/vulkan-1.def`, tag vulkan-sdk-1.4.357.0 bin/vulkan-1.dll built from vulkan-sdk-1.4.357.0 by xlings-res/vulkan-loader's windows workflow, which loads the DLL and resolves vkEnumerateInstanceVersion, vkCreateInstance and vkGetInstanceProcAddr before publishing (run 34608619850) LICENSE.txt Vulkan-Loader's Apache-2.0 -- a redistributed binary carries its license README.md how each file was produced Packed deterministically (sorted, fixed mtime, numeric owner, gzip -n); the sha was computed twice, read back from GitHub, and the gitcode mirror (mcpp-res/vulkan-import 1.4.357.3) is byte-identical. COMPATIBILITY, MEASURED. The DLL exports exactly the 265 names in the .def -- no additions, no omissions -- so every import `vulkan-1.lib` can produce resolves, and no consumer can hit "entry point not found". The loader version the earlier xim payload carried (1.4.313) exports the same 265; the build is at 1.4.357 anyway so the loader matches the headers it is consumed with. On a machine that ALREADY has a GPU driver nothing is lost: the copy beside the executable is found first (the application directory precedes System32), and the loader still reads HKLM\SOFTWARE\Khronos\Vulkan\Drivers, so the driver the machine has is the ICD it uses. The ICD is deliberately not supplied -- a software fallback would hide a missing driver behind a slow device. WHY NEW VERSIONS INSTEAD OF MOVING PINS. An installed copy records the pins it resolved with. Moving a pin inside a published version does not reach a warm store, which is not hypothetical here: with #391's first approach, a warm CI store kept `compat.vulkan@1.4.357.0`, never re-evaluated its closure, and the loader never arrived. That is the same rule as compat.vulkan 1.4.357.1. Versions before 1.4.357.3 have no bin/; mcpp skips a declared runtime directory that does not exist, so `library_dirs` is inert for them. WHY THE TEST ASSERTION IS A REAL CHECK. On Windows the test now requires the mapped vulkan-1.dll to sit in the executable's directory. With an older compat.vulkan that fails on a machine with a driver (the loader comes from System32) and never runs on one without (the process dies first). The `windows-2022` leg of this PR has no system loader at all, so it can only pass if the deployment works. This is also why #391 -- which put the DLL in System32 on the runner -- is superseded rather than merged: it would make that leg pass whether or not the package works. Co-authored-by: sunrisepeak <x.d2learn.org@gmail.com> * fix(eui-neo): find upstream's directory under a re-released version; vulkan-hpp moves to a follow-up TWO THINGS LOCAL VERIFICATION FOUND in the first push of this branch. 1. compat.eui-neo 0.5.9.1 could not install. The install hook looks for the unpacked archive by name, `EUI-NEO-<version>`, and took the version verbatim -- so it looked for `EUI-NEO-0.5.9.1/` in an archive that unpacks to `EUI-NEO-0.5.9/`: eui-neo: no CMakeLists.txt under .../compat-x-eui-neo/0.5.9.1/eui-neo-0.5.9.1 after unpacking; the archive layout is neither wrapped nor flat A fourth version component is this index re-releasing the same upstream tag, so the lookup now drops it. Three-component versions are unchanged; checked directly: 0.5.9 -> 0.5.9, 0.5.9.1 -> 0.5.9, 0.5.10 -> 0.5.10, 1.2.3.45 -> 1.2.3, 0.5.9-rc1 -> 0.5.9-rc1. The `layer` directory keeps the package's own version; the sources are `*/` globs, so its name never mattered. After the fix, locally with mcpp 2026.9.11.2: compat.eui-neo[vulkan]: ok (backend=vulkan, loader api 1.4.357) i.e. eui-neo 0.5.9.1 resolved compat.vulkan 1.4.357.3 through the feature. This is the same class of bug as openxlings/xim-pkgindex#821 fixed in vulkan-loader: a hook deriving a path from the version works exactly until a second version shares an archive. 2. khronos.vulkan-hpp 1.4.357.1 cannot be verified in the same change that introduces compat.vulkan 1.4.357.3. `vulkan-hpp-module` redirects only the `khronos` namespace to this checkout, so `compat` comes from the PUBLISHED index, which does not have 1.4.357.3 until this merges: xlings install_packages failed (exit 1) for 'compat.vulkan@1.4.357.3' with 1 index repo configured [mcpplibs -> https://github.com/mcpplibs/mcpp-index.git] Redirecting `compat` as well was tried and is still refused -- mcpp reports "≥2 project-level index repos is a known xlings resolution gap (mcpp #238; root cause openxlings/xlings#374)" even though #238 is closed. So the khronos.vulkan-hpp bump and its member pin are reverted here and follow once this is merged and the index republished -- the same order openxlings/xim-pkgindex#818 and mcpp-index#391 needed. Consequence for this PR's CI, stated in advance: `vulkan-hpp-module` is still selected (its manifest names vulkan) and still resolves compat.vulkan 1.4.357.0, so on the windows leg it fails exactly as it does on main today. `vulkan` and `eui-neo-vulkan` are the members this change is judged by. Co-authored-by: sunrisepeak <x.d2learn.org@gmail.com> --------- Co-authored-by: sunrisepeak <x.d2learn.org@gmail.com>
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
1 participant
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.
Summary
Adds Windows to
compat.openblas. OpenBLAS has no upstream Make path for the MSVC-ABI Clang mcpp links with, so Windows uses the prebuilt x64 zip: link the MSVC import lib (lib/libopenblas.lib) and ship the runtime DLL (bin/libopenblas.dll) beside the consumer's .exe. mcpp ≥ 0.0.73 stages a dependency's[runtime] library_dirs*.dllnext to the executable (PE has no RPATH), so a standalone launch finds it.Recipe (
pkgs/c/compat.openblas.lua)xpm.windows:OpenBLAS-0.3.33-x64.zip(GLOBAL = OpenMathLib GitHub; CN = gitcodemcpp-res/openblas, uploaded + GET-verified byte-equal, sha2567ad797ef…). Unpacks tobin/ lib/ include/(no wrapper dir).mcppldflags are now per-OS — the synthesized-manifest parser appends ldflags, so a global-lopenblaswould wrongly reach the Windows link. linux/macosx link static-lopenblas; windows links-llibopenblas(clang MSVC maps it tolibopenblas.lib).mcpp.windows:[runtime] library_dirs=["bin"](DLL deploy) + agenerated_filesanchor TU (no Make build on Windows).install()returns immediately on windows; linux/macosx keep the source build (the asymmetry is intentional — only Windows ships a runtime DLL).Windows CI (Phase D)
smoke_compat_portable.shgains a Windows-only OpenBLAS build-AND-run:cblas_dgemmmust produce exactly[19 22; 43 50], and the produced.exeis launched directly from a neutral CWD so a clean exit proves the DLL was actually deployed beside it (not merely found viamcpp run's PATH prepend).MCPP_VERSION0.0.68 → 0.0.73(the release carrying runtime-DLL deployment; mirrored + indexed).The Linux/macOS static-archive path is unchanged. See mcpp
.agents/docs/2026-06-29-windows-runtime-dll-deployment-and-openblas.md.