I’m trying out Nix on Pop!_OS, an Ubuntu-based distribution. I have a home-manager config which includes config for some GUI programs, like Qutebrowser and Alacritty. However, none of them seem to work. CLI and TUI programs work just fine, just not any GUI programs. Running alacritty from inside gnome-terminal gives this:
Error: Error creating GL context; Received multiple errors. Errors: `[OsError("Could not create EGL display object"), OsError("`glXQueryExtensionsString` found no glX extensions")]`
I’m not knowledgeable about your specific issue, but generally speaking I can at least assure you there’s not a nix-intrinsic reason that would prevent GUI apps from working.
Here’s a screenshot of me running alacritty on macOS:
The system needs to provide the hardware-acceleration libraries needed for your GPU, however, there’s no good way to tell nix this in a pure fashion.
What’s the nixpkgs solution?
addOpenGLRunpath will add /run/opengl-driver/lib to the RUNPATH of ELFs, which will allow for the executables to find the required graphics libraries at runtime. The only OS which supports this convention is NixOS, so if you’re on NixOS you get this behavior by default; other distro’s, not so much. A poor man’s solution on non-NixOS would be to just to symlink /run/opengl-driver/lib to where your system installs graphics libraries, but you will probably run into ABI issues; thus will recommend using nixGL
But are you saying that to get any GUI program to work from Nixpkgs, I have to:
I mean, all of the solutions will be trying to get around how C dynamic linking works. You could set LD_LIBRARY_PATH to the graphics libraries (which is what nixgl does under the covers), but likely to hit ABI issues unless you do LD_PRELOAD on the latest libc.
You could do something like:
sudo mkdir -p /run/opengl-driver/lib
graphics_libs=(/usr/lib/lib{cuda,EGL,glx,GL,nvidia,nvoptix,vulkan}*)
for lib in ${graphics_libs[@]}; do
sudo ln -s "$lib" /run/opengl-driver/lib/
done
And that might work fine, assuming ABI compatibility, but graphics libraries don’t usually change too much. You will need to run this each boot, as /run/ is usually tmpfs, and thus will clear between restarts.
This is really the exception, out of the 60-80k packages, only a few hundred are GUIs.
Also, cross-platform tools like home-manager have usage of admins commands as an explicit non-goal. Nixpkgs is not meant to be opinionated about how the system is configured. NixOS modules can be opinionated, but modules also have the ability to realize their assumptions.
The fact that I had to use sudo for the linking should indicate that the linking is a system issue, not a userspace issue.
And that could automatically do all this linking. It seems unusual to have users have to do all this manually, just to get something to work.
It does “just work” if you’re on NixOS You should join us
Would it be hard to have a global option for modifying all the system’s .desktop items to include nixGL? I guess makeDesktopItem isn’t used in general, unfortunately…
I expect this could trigger some hefty rebuilds. Perhaps one could instead build on top of nixGL and make a solution that that generates the appropriate /run/opengl-driver/lib on a non-NixOS system. Perhaps at some point a tool like that could even be distributed alongside with nix
nixGL is creating a sandbox and using LD_LIBRARY_PATH to force nix ABI, I don’t think that’s desirable default behavior.
My recommendation is that if you want to use GUI applications, use the native package manager to do so, as it will be aware of how to expose your hardware acceleration libraries.
To be 100% honest, these issues can also occur in NixOs, I also got bitten once Blender segfaults at startup · Issue #1 · edolstra/nix-warez · GitHub . And saying that graphic programs are edge-cases… well my grand-mother would definitely not agree ^^ And I guess the advantage of using Nix over package managers like apt in debian, is that not only you can easily get more up to date softwares, but most importantly maybe is that it lets you build programs using the same version of the libraries on many systems. So if we want projects to use nix to setup build environments for big projects (I saw that Zulip has this plan!), shouldn’t we consider this issue seriously?
For the last 20 months or so my current configuration (NixOS on the stable nixos channel + home-manager on unstable) was working fine, when the things were green on hydra: https://status.nixos.org/.
Please, could you share a link - is it mentioned somewhere in the documentation that we should not be mixing stable NixOS with unstable packages running on top of it?
What is the guarantee that it will not happen on the stable NixOS plus stable nixpkgs?
To be honest I might switch my hm to stable channel once the next release happens anyway
You should join us 
