Several especially interesting episodes lately. You are doing a good job here @mightyiam !
1 Like
sorry in advance to reply only to the preview/title, but i tackled the libGL impurity issue and “solved” it for anybody who can tolerate longer rebuilds: overlay.
the libGL “impurity” is worse than that – it’s actually a nascent cyclic dependency. mesa dispatches to /run/opengl-driver, which for a default system, is provided by mesa. the dependency chain is mesa → vulkan-loader → mesa: this would infinitely recurse at eval, but by replacing one of these nodes with /run/opengl-driver we “break” the cycle.
except that the whole idea is bunk.
- try running a graphical nix app on a CentOS machine: it’ll complain about /run/opengl-driver not existing. so create it and symlink the CentOS libgl.so: then it’ll complain about glibc version conflicts.
- try running any graphical app from
pkgsMusl.*on a stock glibc NixOS system. it’ll crash: you can’tdlopenan object linked for glibc into a process already running musl.
i’ve heard 2 reasons why /run/opengl-driver exists:
- that libgl is hardware specific so nix-built binaries couldn’t be portable across non-nix systems if nix were to supply this itself.
- NVIDIA users require libgl to exactly match the kernel version in use: without this impurity we would be always recompiling the world.
neither of these stand up to scrutiny. no. 2 is quite the opposite way: the reason i’m always rebuilding is that patching out this impurity means i can’t pull so much from cache.nixos.org.
i’ve seen proposals around “vulkan-loader et al should try /run/opengl-driver, then fallback to pkgs.mesa” or something. it’s been years and AFAICT nobody’s done that yet. meanwhile other maintainers in this area seem reluctant to link the nix mesa as a backend directly, instead of going through /run/opengl-driver. idk how to get any movement on this.
4 Likes
Thank you for sharing. Do you think you can submit a PR that would improve the situation in any way, or at least suggest a more appropriate approach?