Code change:
| Find libraries | `configurePhase` | Missing dependency on a `dev` output | Add the missing dependency | The `dev` output typically contain CMake configuration files | | Find libraries | `buildPhase` or `patchelf` | Missing dependency on a `lib` or `static` output | Add the missing dependency | The `lib` or `static` output typically contain the libraries | <del> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`cudaPackages.autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=cudaPackages.autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </del> <ins> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </ins>

Related discussion:
text: Directory renaming is now out of scope This directory is also being used as the way to get access to the host machines gpu drivers. I think it's another source of confusion for many users to have to add so that they can get a vulkan game / cuda workload / opencl workload to work. I think we should deprecate this prior to the 21.11 release, and fully move it to something like or something more representative of the desired affect. This was done in cc EDIT: roadmap (2.5 years later... lol): addOpenGLRunpath -addDriverRunpath Init addDriverRunpath: Deprecate : -autoAddDriverRunpath Init autoAddDriverRunpath: Deprecate cudaPackages.autoAdd{OpenGLRunpathHook,DriverRunpath}: NixOS Module changes: TODO
For the transition period ( NixOS 21.11), I think keeping the old would help alleviate a lot of the pain, would just like to get the ball rolling away from using explicitly
I agree. Also, on a related note, having to specify your graphics driver at the xserver level in the module system feels wrong to me. I'm still not exactly sure how it maps given names to driver packages either.
I propose two changes: move -- make a symlink to for backwards compatibility of existing derivations -- add a
potential future work as well: -- Until 21.11 EOL, have it add both and , to avoid system vs package invariance
I'm also kind of wondering whether is just another fallacy in naming, and we should really be exposing something like, would be even more appropriate, as other hardware-accelerated devices such as tpus, fpga's, and others would also likely need to import "libraries which are determined by the system, and need to be available at runtime".
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Should we, in addition, consider using a libc-versioned directory? Motivated by
Decided to rename this issue since renaming the underlying path was deemed too risky for potential breakages.
Could you provide some context as to why? My naive assumption was that we'd have a new path but: have both new and legacy path to rpath via the hook; new path preferred provide a legacy symlink pointing at the new path in NixOS which would be quite trivial.