You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* feat(glx-runtime): GL comes from the ecosystem, not from /usr/lib
This package symlinked the HOST's libGL/libEGL out of /usr/lib*. That is what
mcpp#352 is: the host's Mesa needs GLIBC_2.43, mcpp's payload glibc is 2.39,
and the program linked cleanly then exited 255 with no output at all. It is
also the first entry on the xlings hermetic policy's forbidden list -- any .so
under /usr/lib* or /lib*.
2026.08.08 takes the same libraries from `xim:graphics`: 22 packages plus two
sentinels that probe for a host-side userspace half they do not own (the
proprietary NVIDIA driver, WSL2's D3D12) and succeed having linked nothing
when it is absent. One dependency covers every host shape and this file gained
no conditional.
The source is the SUBOS VIEW, not a payload directory. A payload path pins a
version, so a consumer's RUNPATH would name mesa 25.0.7.1 forever and break
the day it is upgraded; the view is the stable indirection, the role
/run/opengl-driver plays on NixOS.
The view also carries libc.so.6 and the rest of the C runtime, and those must
never reach a consumer's RUNPATH -- the consumer runs under mcpp's payload
loader, and a second libc paired with it faults inside the dynamic linker
before main with no output. The pattern list is what keeps them out, so it is
now a safety boundary with an assertion behind it rather than a convenience.
That failure was reproduced on the way here, not imagined.
libnvidia* leaves the pattern list: the proprietary driver reaches the subos
through xim:nvidia-gl-host-link under the glvnd vendor names already matched,
and taking it by its own name too would be a second route to one set of
libraries.
MCPP_HOST_GL_LIBRARY_PATH still works and is now the only door back to the
host. It warns when used, because what it names was built against the host's
glibc and loading it under the payload's is the #352 configuration exactly.
Verified on an NVIDIA host, not reasoned about: a consumer whose RUNPATH is
the generated directory resolves libEGL to it, and GL_RENDERER is "NVIDIA
GeForce RTX 4080". Both halves are the criterion -- "a window appeared" is a
false pass, since llvmpipe produces one too. The no-libc assertion was checked
against the real view: 52 libraries linked, zero C-runtime entries.
2026.06.03 stays published so consumers already pinned to it keep resolving.
compat.glfw, the only package that depends on this one, moves to the new pin.
* fix(glx-runtime): deps belong beside the version entries, not inside one
CI: `E_INTERNAL: [glx-runtime] failed:` with an empty message, twice. The
`deps = { runtime = { "xim:graphics" } }` had been placed inside the
2026.08.08 version entry. The descriptor parsed, the graphics stack was never
installed, the subos therefore had no libGL.so.1, and the install failed on
the required-library check -- reporting the library rather than the misplaced
key, which is why the message looked like a missing package instead of a
typo.
Every other recipe in both indexes puts deps at platform level. Moving it
there means the legacy 2026.06.03 entry declares it too and pays for a
download it does not read; the alternative is deleting a published version,
which breaks anyone pinned to it outright.
0 commit comments