Do GUI applications not work on non-NixOS (using nixpkgs only)?

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")]`
1 Like

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:

1 Like

You want to look at GitHub - guibou/nixGL: A wrapper tool for nix OpenGL application

Whats the underlying issue?

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

5 Likes

Thanks! But are you saying that to get any GUI program to work from Nixpkgs, I have to:

  1. Install NixGL
  2. Edit the .desktop file of any Nix-installed GUI package, and prefix nixgl to the exec call

and do that for each GUI program I want to run as expected?

3 Likes

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.

1 Like

There should ideally be an option to make GUI programs work in non-NixOS, no?

Something like:

system.nonNixOS = true;

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.

1 Like

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 :slight_smile: You should join us :tada:

4 Likes

…yes, getting a nice behaviour for this tiny little edge-case was exactly the motivation for my switch from arch+nix to NixOS a while back:)

It’s an edge-case that exists for a good reason, but that also has yet to have been handled properly in terms of UX

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…

1 Like

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.

1 Like

Since I last used nixGL, its gained a flake.nix and an auto detect feature.

So with flakes, now you can just type:
nix run --impure github:guibou/nixGL -- <program>

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?

Since similar issues are occuring also for other libs (in particular GLIBC, see Solve the libGL ABI problem · Issue #31189 · NixOS/nixpkgs · GitHub ), shouldn’t we try to adress all impurities properly? I was thinking to automatically add a wrapper to GUI app that automatically configures NixGl if required, checks if the GLIBC used by the system is not too old etc… Solve the libGL ABI problem · Issue #31189 · NixOS/nixpkgs · GitHub

Hosted by Flying Circus.