feat(compat.opencl): the loader builds on Windows, and the test stops skipping there - #379
Merged
Merged
Conversation
… skipping there The package had linux and macosx entries and no windows one, so a Windows consumer had no OpenCL loader to link and `tests/examples/opencl` compiled to a printed skip. The gap was stated in the recipe and tracked nowhere. Upstream has supported Windows all along: `loader/windows/` enumerates drivers from `HKLM\SOFTWARE\Khronos\OpenCL\Vendors`, from the display adapters through DXGK, and from installed app packages, and loads each with LoadLibrary. The section here is upstream's WIN32 source list with upstream's two link libraries, `cfgmgr32` and `runtimeobject`. NO RUNTIME ADAPTER, AND THE ASYMMETRY IS THE POINT. `compat.opencl-runtime` exists to undo mcpp's PRIVATE loader on Linux, where a bare-soname dlopen from inside an mcpp binary does not search the host's library path. A Windows artifact runs under the system loader and every registry entry names a DLL by absolute path, so there is nothing to undo -- this platform gets a loader with no adapter beside it. STATIC, as on macOS. A program that wants THE system loader links the vendor's `OpenCL.lib` against `C:\Windows\System32\OpenCL.dll`; a package shipping a second `OpenCL.dll` would compete with that rather than converge on it. Static also keeps `loader/windows/OpenCL.def` out of the build, which only a DLL needs. The member test now declares the dependency unconditionally and its skip branch says what it actually means -- built without the loader -- rather than naming a platform that no longer lacks one. Linux is unchanged and still reports `platform: NVIDIA CUDA / device: NVIDIA GeForce RTX 4080` on a machine with a driver. The Windows half is verified by this repository's `workspace (windows default)` job, which is the only Windows available to the change.
… auto-linked The first Windows section carried upstream's two link libraries and nothing else, because that is all upstream's CMakeLists names. MSVC never has to name the rest: its SDK headers pull the default import libraries in through `#pragma comment(lib, ...)`. mcpp links with lld and does not inherit that. The build compiled cleanly and failed at link with nine undefined symbols -- eight registry and process-token calls and `StringFromGUID2` -- so advapi32 and ole32 are named here. Measured on this repository's Windows job, which is the only Windows this change has. The compile was never the criterion.
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.
Closes the one stated gap in this index's OpenCL support.
What was missing
compat.openclhadlinuxandmacosxxpm entries and nowindowsone, so a Windows consumer had no loader to link andtests/examples/openclcompiled to a printed skip:The gap was stated in the recipe and tracked nowhere, which is how a skip becomes permanent.
What upstream already has
loader/windows/enumerates drivers fromHKLM\SOFTWARE\Khronos\OpenCL\Vendors, from the display adapters through DXGK, and from installed app packages, and loads each withLoadLibrary. This section is upstream's WIN32 source list and upstream's two link libraries,cfgmgr32andruntimeobject, in the spelling this index uses for a Windows system library.No runtime adapter, and the asymmetry is the point
compat.opencl-runtimeexists to undo mcpp's private loader on Linux: a bare-sonamedlopenfrom inside an mcpp binary does not search the host's library path. A Windows artifact runs under the system loader and every registry entry names a DLL by absolute path, so there is nothing to undo. This platform gets a loader with no adapter beside it.Static, as on macOS
A program that wants the system loader links the vendor's
OpenCL.libagainstC:\Windows\System32\OpenCL.dll; a package shipping a secondOpenCL.dllwould compete with that rather than converge on it. Static also keepsloader/windows/OpenCL.defout of the build — only a DLL needs it.Criterion
The
workspace (windows default)job here is the only Windows available to this change: it builds the member and runs it. Zero platforms is a pass on a runner with no driver, which is what the test already asserts and prints.Linux is unchanged, measured on a host with a driver: