Found by mcpp's new dlopen-surface check (mcpp-community/mcpp#598), whose first catch is this index's own package. Reported rather than repaired in that PR: the repair belongs here, with its own criterion.
Measured
Host: Linux x86_64, NVIDIA driver 550.144.03, compat:vulkan-runtime@2026.09.07, built through examples/09-heterogeneous/vulkan.
warning: 4 of 55 libraries a dependency published for dlopen cannot be loaded
on this artifact's search path:
libnvidia-encode.so.1 needs libnvcuvid.so.1
libnvidia-opticalflow.so.1 needs libnvcuvid.so.1
libnvidia-pkcs11-openssl3.so.550.144.03 needs libcrypto.so.3
libnvidia-pkcs11.so.550.144.03 needs libcrypto.so.1.1
All four sonames are present in /usr/lib/x86_64-linux-gnu on that host and absent from the farm (76 entries).
Why it is the same shape as mcpp#596
The farm mirrors a proprietary driver family and stops one library short. Nothing reports a back end that fails to load, so the consequence is a capability that is simply absent at run time — NVENC and optical flow through Vulkan, and the PKCS#11 modules.
Unlike #596 this is not on the default path of any example, so it has no measured user-visible failure yet. That is why it is an issue rather than a hotfix.
What a repair needs
The header says the farm carries "the libraries the host's manifests name, the transitive set they need as ldd reports it, and the proprietary vendor family". These four are in the transitive set and were not picked up, so the question is which of the three rules missed them rather than which names to add — a hand-written addition would leave the next one to be found the same way.
A criterion is available now and did not exist before: build a project depending on this package on a host with the driver and assert runtime.dlopen_surface in resolution.json reports no "kind": "missing" finding. On a runner with no NVIDIA driver the farm is nearly empty and the check is silent, so the assertion has to say which machine it is making a claim about.
Found by mcpp's new dlopen-surface check (mcpp-community/mcpp#598), whose first catch is this index's own package. Reported rather than repaired in that PR: the repair belongs here, with its own criterion.
Measured
Host: Linux x86_64, NVIDIA driver 550.144.03,
compat:vulkan-runtime@2026.09.07, built throughexamples/09-heterogeneous/vulkan.All four sonames are present in
/usr/lib/x86_64-linux-gnuon that host and absent from the farm (76 entries).Why it is the same shape as mcpp#596
The farm mirrors a proprietary driver family and stops one library short. Nothing reports a back end that fails to load, so the consequence is a capability that is simply absent at run time — NVENC and optical flow through Vulkan, and the PKCS#11 modules.
Unlike #596 this is not on the default path of any example, so it has no measured user-visible failure yet. That is why it is an issue rather than a hotfix.
What a repair needs
The header says the farm carries "the libraries the host's manifests name, the transitive set they need as
lddreports it, and the proprietary vendor family". These four are in the transitive set and were not picked up, so the question is which of the three rules missed them rather than which names to add — a hand-written addition would leave the next one to be found the same way.A criterion is available now and did not exist before: build a project depending on this package on a host with the driver and assert
runtime.dlopen_surfaceinresolution.jsonreports no"kind": "missing"finding. On a runner with no NVIDIA driver the farm is nearly empty and the check is silent, so the assertion has to say which machine it is making a claim about.