std-freestanding 0.5.0 - #238
Merged
Merged
Conversation
Windows 的 llvm 载荷不带 libc++,于是 build.mcpp 从 0.5.0 起看第二处: 已安装的 xim:libcxx-headers。索引侧只需 windows 平台加一条 deps。 deps 是按平台而非按版本的,于是它也套到 0.2.0–0.4.0 上 —— 那几版在 Windows 上本来就构建不出来,代价是一次小下载。
Sunrisepeak
added a commit
that referenced
this pull request
Sep 11, 2026
…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>
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.
0.5.0 让
build.mcpp在工具链载荷之外再看一处:已安装的xim:libcxx-headers。Windows 的 llvm 载荷把 clang 编译在 MSVC 标准库上、不带 libc++,所以那一行此前只能断言缺口。现在它真正构建。
0.5.0行(GLOBAL + CN 双端,CN 已回探逐字节核对)deps = { "xim:libcxx-headers@22.1.8" }deps是按平台而非按版本的,于是也套到 0.2.0–0.4.0 —— 那几版在 Windows 上本就构建不出来。