|
33 | 33 | -- this through `APPLE_STATIC_LOADER` + pthread_once; Linux through |
34 | 34 | -- `__attribute__((constructor))`. Windows has neither. |
35 | 35 | -- |
36 | | --- The supported Windows arrangement is the ordinary one every Vulkan |
37 | | --- application uses: link `vulkan-1.lib` and let the system `vulkan-1.dll`, |
38 | | --- installed by any GPU driver, do the ICD loading. The windows xpm entry is |
39 | | --- therefore a small artifact carrying that import library — symbol stubs, no |
40 | | --- code — generated from Khronos' own `loader/vulkan-1.def` (shipped in this |
41 | | --- very loader tarball) with a single reproducible command: |
| 36 | +-- The supported Windows arrangement is the ordinary one: link `vulkan-1.lib` |
| 37 | +-- and load `vulkan-1.dll` at process start. Through 1.4.357.2 that DLL was |
| 38 | +-- assumed to come from the machine's GPU driver, which a driverless machine |
| 39 | +-- does not have (0xC0000135 before `main`, measured on `windows-2022`). From |
| 40 | +-- 1.4.357.3 the artifact also carries the DLL, built from the same tag, and |
| 41 | +-- `runtime.library_dirs` has mcpp place it beside every consuming executable; |
| 42 | +-- see the windows xpm entry. The import library in that artifact — symbol |
| 43 | +-- stubs, no code — is generated from Khronos' own `loader/vulkan-1.def` |
| 44 | +-- (shipped in this very loader tarball) with a single reproducible command: |
42 | 45 | -- |
43 | 46 | -- llvm-dlltool -d vulkan-1.def -l lib/vulkan-1.lib -m i386:x86-64 |
44 | 47 | -- |
@@ -89,6 +92,16 @@ package = { |
89 | 92 | -- version -- and where a consumer also names the farm directly, the |
90 | 93 | -- two disagree and the build stops. Measured on a CI runner with a |
91 | 94 | -- warm ~/.mcpp; see the note on compat.vulkan 1.4.357.1. |
| 95 | + -- 1.4.357.3: the same loader source. A new version on every platform |
| 96 | + -- because the WINDOWS artifact changed -- it now carries the loader DLL |
| 97 | + -- (see the windows entry) -- and a version is one key across platforms. |
| 98 | + ["1.4.357.3"] = { |
| 99 | + url = { |
| 100 | + GLOBAL = "https://github.com/KhronosGroup/Vulkan-Loader/archive/refs/tags/vulkan-sdk-1.4.357.0.tar.gz", |
| 101 | + CN = "https://gitcode.com/mcpp-res/vulkan/releases/download/1.4.357.0/vulkan-1.4.357.0.tar.gz", |
| 102 | + }, |
| 103 | + sha256 = "54f2537df22313768da0317dda2abdaaab7711b4081c48c869a79db343d0ae70", |
| 104 | + }, |
92 | 105 | ["1.4.357.2"] = { |
93 | 106 | url = { |
94 | 107 | GLOBAL = "https://github.com/KhronosGroup/Vulkan-Loader/archive/refs/tags/vulkan-sdk-1.4.357.0.tar.gz", |
@@ -136,6 +149,16 @@ package = { |
136 | 149 | -- version -- and where a consumer also names the farm directly, the |
137 | 150 | -- two disagree and the build stops. Measured on a CI runner with a |
138 | 151 | -- warm ~/.mcpp; see the note on compat.vulkan 1.4.357.1. |
| 152 | + -- 1.4.357.3: the same loader source. A new version on every platform |
| 153 | + -- because the WINDOWS artifact changed -- it now carries the loader DLL |
| 154 | + -- (see the windows entry) -- and a version is one key across platforms. |
| 155 | + ["1.4.357.3"] = { |
| 156 | + url = { |
| 157 | + GLOBAL = "https://github.com/KhronosGroup/Vulkan-Loader/archive/refs/tags/vulkan-sdk-1.4.357.0.tar.gz", |
| 158 | + CN = "https://gitcode.com/mcpp-res/vulkan/releases/download/1.4.357.0/vulkan-1.4.357.0.tar.gz", |
| 159 | + }, |
| 160 | + sha256 = "54f2537df22313768da0317dda2abdaaab7711b4081c48c869a79db343d0ae70", |
| 161 | + }, |
139 | 162 | ["1.4.357.2"] = { |
140 | 163 | url = { |
141 | 164 | GLOBAL = "https://github.com/KhronosGroup/Vulkan-Loader/archive/refs/tags/vulkan-sdk-1.4.357.0.tar.gz", |
@@ -183,6 +206,37 @@ package = { |
183 | 206 | -- version -- and where a consumer also names the farm directly, the |
184 | 207 | -- two disagree and the build stops. Measured on a CI runner with a |
185 | 208 | -- warm ~/.mcpp; see the note on compat.vulkan 1.4.357.1. |
| 209 | + -- 1.4.357.3: THE LOADER DLL SHIPS WITH THE IMPORT LIBRARY. |
| 210 | + -- |
| 211 | + -- `vulkan-1.dll` is not a Windows component: it arrives with a GPU |
| 212 | + -- driver, with LunarG's Vulkan Runtime redistributable, or beside an |
| 213 | + -- application. So a machine without a driver has no loader, and a |
| 214 | + -- program linking `vulkan-1.lib` dies before `main` with 0xC0000135 |
| 215 | + -- (STATUS_DLL_NOT_FOUND). Measured on GitHub's `windows-2022` image |
| 216 | + -- (mcpp-index #387 probe; `vulkan`, `eui-neo-vulkan` and |
| 217 | + -- `vulkan-hpp-module` all failed that way). |
| 218 | + -- |
| 219 | + -- The artifact adds `bin/vulkan-1.dll`, built from |
| 220 | + -- `vulkan-sdk-1.4.357.0` -- the same tag as the headers and the .def -- |
| 221 | + -- by xlings-res/vulkan-loader's windows workflow, which loads the DLL |
| 222 | + -- and resolves its entry points before publishing. `lib/vulkan-1.lib` |
| 223 | + -- is byte-identical to 1.4.357.1's, and the DLL exports exactly the |
| 224 | + -- 265 names in `vulkan-1.def`: every import that library can produce |
| 225 | + -- resolves, so no consumer can hit "entry point not found". |
| 226 | + -- |
| 227 | + -- ON A MACHINE THAT ALREADY HAS A DRIVER nothing is lost. The copy |
| 228 | + -- beside the executable is found first (the application directory |
| 229 | + -- precedes System32), and the loader still reads |
| 230 | + -- HKLM\SOFTWARE\Khronos\Vulkan\Drivers, so the GPU driver the |
| 231 | + -- machine has is the ICD it uses. This is the ordinary arrangement for |
| 232 | + -- an application that redistributes the loader. |
| 233 | + ["1.4.357.3"] = { |
| 234 | + url = { |
| 235 | + GLOBAL = "https://github.com/xlings-res/vulkan-import/releases/download/1.4.357.3/vulkan-import-1.4.357.3.tar.gz", |
| 236 | + CN = "https://gitcode.com/mcpp-res/vulkan-import/releases/download/1.4.357.3/vulkan-import-1.4.357.3.tar.gz", |
| 237 | + }, |
| 238 | + sha256 = "8118f1bd897e553baffabf484a14db980ce1f0a6cfdb5a6222c0a236ecdf12f5", |
| 239 | + }, |
186 | 240 | ["1.4.357.2"] = { |
187 | 241 | url = { |
188 | 242 | GLOBAL = "https://github.com/xlings-res/vulkan-import/releases/download/1.4.357.1/vulkan-import-1.4.357.1.tar.gz", |
@@ -359,15 +413,26 @@ package = { |
359 | 413 | -- .def it came from. The anchor keeps a buildable target, the same |
360 | 414 | -- shape `compat.opengl` uses for a headers-only package. |
361 | 415 | -- |
362 | | - -- The artifact is packed FLAT — lib/ at the archive root, no wrap |
363 | | - -- directory — because `-L` is not glob-expanded the way |
| 416 | + -- The artifact is packed FLAT — lib/ and bin/ at the archive root, no |
| 417 | + -- wrap directory — because `-L` is not glob-expanded the way |
364 | 418 | -- include_dirs and sources are. With a wrap layer the relative |
365 | 419 | -- `-Llib` below misses and the link fails with |
366 | 420 | -- "LNK1181: cannot open input file 'vulkan-1.lib'". |
367 | 421 | sources = { "mcpp_generated/vulkan_import_anchor.c" }, |
368 | 422 | ldflags = { "-Llib", "-lvulkan-1" }, |
369 | 423 | runtime = { |
370 | | - -- vulkan-1.dll ships with the GPU driver, not with us. |
| 424 | + -- THE LOADER TRAVELS WITH THE PROGRAM (1.4.357.3+). mcpp copies |
| 425 | + -- every *.dll under a dependency's runtime library_dirs beside the |
| 426 | + -- executable it builds -- for transitive dependencies too -- and |
| 427 | + -- `mcpp pack` always searches the executable's own directory, so |
| 428 | + -- the same file reaches a packed distribution. Versions before |
| 429 | + -- 1.4.357.3 have no bin/ in their artifact; mcpp skips a declared |
| 430 | + -- directory that does not exist, so for them this is inert. |
| 431 | + -- |
| 432 | + -- The ICD is deliberately NOT supplied: on a machine with a GPU |
| 433 | + -- driver the driver's ICD is the right one, and a software |
| 434 | + -- fallback would hide a missing driver behind a slow device. |
| 435 | + library_dirs = { "bin" }, |
371 | 436 | dlopen_libs = { "vulkan-1.dll" }, |
372 | 437 | capabilities = { "vulkan.icd.driver" }, |
373 | 438 | }, |
|
0 commit comments