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


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?


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


for lib in ${graphics_libs[@]}; do
    sudo ln -s "$lib" /run/opengl-driver/lib/

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:


…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>

1 Like

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

I’m on the latest NixOS 21.11 with home-manager pinned to the latest unstable nixpkgs and I just got this error today:

I’m using xfce4-terminal as a workaround for now :disappointed:

Since I just have it in fresh memory, did you install alacritty with a user channel and/or nix-env, so it never updated with the rest of your system?

Alternatively it’s possible unstable’s driver has moved on, too. Mixing stable/unstable for GUI things is rarely a good idea.

As mentioned in the comment in the GH issue:

I’m on the home-manager with nixpkgs pinned to:

    "nixpkgs-unstable": {
        "branch": "nixpkgs-unstable",
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "52dc75a4fee3fdbcb792cb6fba009876b912bfe0",
        "sha256": "1mc7qncf38agvyd589akch0war71gx5xwfli9lh046xqsqsbhhl0",

I’m using niv for pinning the dependencies: GitHub - nmattia/niv: Easy dependency management for Nix projects

It is always executed in the nix-shell (I always upgrade from inside the nix-shell).

This is the template I am using: GitHub - ryantm/home-manager-template: A quick-start template for using home-manager in a more reproducible way.

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:

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 :thinking: :man_shrugging: