test(examples): the GL members pin the glfw that carries the new farm - #384
Merged
Conversation
`compat.glfw` took 3.4.0.1 when its pin on `compat.glx-runtime` moved to 2026.09.11, and nothing moved with it: `imgui-window` and `gui-stack` still pinned 3.4, so they resolved the old chain and the bump was inert. A version nobody pins is a version nobody exercises -- these two are the only members that reach the GL farm at all. Both build against compat.glx-runtime@2026.09.11. They are libraries rather than programs, so mcpp's dlopen-surface check does not apply to them and says so; the farm's own closure is asserted structurally, by reading each member's DT_NEEDED against the farm alone. Measured on this host: the farm is 86 members with no unmet soname and no entry taken directly from /usr/lib -- four route through xim:nvidia-gl-host-link, twenty-eight through other xim payloads, the rest through the subos view. A probe that dlopens every member opens all 86; that probe cannot isolate the farm from the subos, which a control confirmed, so it is evidence that the members load and not that the farm alone suffices.
…this package's version `install()` fell back to `"glfw-" .. pkginfo.version()`. That was the same string for as long as the package had one version; the day it took an ecosystem segment -- 3.4.0.1, for a pin that moved while upstream did not release -- the expression asked for `glfw-3.4.0.1/`, which no tarball contains. install() then moved nothing, and the failure appeared two layers away as `GLFW/glfw3.h: file not found` in a consumer's test. A path derived from a version breaks the first time the version means something the upstream tag does not. The fallback now names the tag, and a source tree that is missing under both spellings is an error rather than an install that "succeeds" and leaves a directory with no headers in it. Found by CI, not locally: `mcpp build` does not compile a member's tests, so the local check was weaker than the one that caught it.
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.
compat.glfwtook 3.4.0.1 when its pin oncompat.glx-runtimemoved to 2026.09.11 (#383), and nothing moved with it:imgui-windowandgui-stackstill pinned3.4, so they resolved the old chain and the bump was inert.These two are the only members in the repository that reach the GL farm at all — so without this, the new
compat.glx-runtimeis exercised by no consumer anywhere in CI.What was measured on this host
Both members build against
compat.glx-runtime@2026.09.11. They are libraries rather than programs, so mcpp's dlopen-surface check correctly does not apply and says so in the record (reason: this build produces no program) rather than reporting a clean-looking0 of 0.The farm's own closure is asserted structurally — each member's
DT_NEEDEDread against the farm alone:A probe that
dlopens every member opens all 86. That probe cannot isolate the farm from the subos — a control (removinglibLLVM.so.20.1from the farm) still reported no failures, because the subos view backs it up — so it is evidence that the members load, not that the farm alone suffices. The farm-alone property rests on the structural walk, which is the shapetests/examples/sycl-runtime/tests/farm.cppalready uses for the same reason.