Why OpenGL drivers (userspace libraries) are installed as system profile dependencies, not application dependencies?

Development
1

NixOS mostly does a good job avoiding application breakage on updates by always keeping exact instances of all runtime dependencies which they had been built against, but OpenGL is another thing. I’ve noticed that OpenGL applications which are installed in user profile break after system upgrade, failing to start because updated OpenGL library can’t work with glibc instance which the application was built against, e. g.:

libGL: dlopen /run/opengl-driver/lib/dri/r600_dri.so failed (/nix/store/hwwqshlmazzjzj7yhrkyjydxamvvkfd3-glibc-2.26-131/lib/libm.so.6: version GLIBC_2.27’ not found (required by /run/opengl-driver/lib/dri/r600_dri.so))`

It seems that /run/opengl-driver is symlink to opengl-drivers store path which is only referred by nixos-system path and not a single application. Had it been installed as application dependency, the instance which broken application had been built against would still be present and it would run. So why had NixOS crew taken decision to do it another way?

1 Like
2

I’ve got a good answer on reddit: https://www.reddit.com/r/NixOS/comments/aewwx4/why_opengl_drivers_userspace_libraries_are/edv231p

1 Like
3

shatsky via Nix community nixos1@discoursemail.com writes:

NixOS mostly does a good job avoiding application breakage on updates
by always keeping exact instances of all runtime dependencies which
they had been built against, but OpenGL is another thing. I’ve noticed
that OpenGL applications which are installed in user profile break
after system upgrade, failing to start because updated OpenGL library
can’t work with glibc instance which the application was built
against

AFAIK the problem is that a program built with one OpenGL library will
fail to run on an X server that’s built with another. So having each
application use its own OpenGL library wouldn’t actually make them work.

I’ve tried using GitHub - nix-community/nixGL: A wrapper tool for nix OpenGL application [maintainer=@guibou] to work around these
incompatibilities, mostly so I could run old versions of Firefox without
rebuilding them. It seemed to work for a while, but recently I’ve been
hitting these OpenGL errors again (haven’t bothered investigating yet)

:frowning:

1 Like
5

AFAIK the problem is that a program built with one OpenGL library will
fail to run on an X server that’s built with another.

I don’t think so, OpenGL library which application uses for direct rendering is the one in its process, not the one in X server process. Here is diagram of how it works altogether, anyone please correct me if I’m wrong:

app<-(1)->libGL<-(2)->libGLX<-(3)-------------------------->X server<-(4)->display buffer
               <-(5)->DRI library<-(6)->window buffer<-(7)->X server<-(4)->display buffer
  • (1), (2), (5) are shared library calls; app, libGL and DRI driver library should work together in a single process
  • (3) is X protocol, it doesn’t break if GLX library uses one libc and X server user another
  • (6) is driver-specific interface between userspace DRI library and kernel DRI driver, both GPU-specific; also doesn’t break
  • (3), (4) and (7) is driver-specific interface between userspace X driver module and kernel graphics card driver; also doesn’t break (it could break if X server and its driver module matching kernel driver are built against incompatible common libraries, but X driver module is X server dependency so this can’t happen in NixOS)

Again: app, libGL, GLX and DRI libraries work together in a single process. It’s (5) which gets broken because DRI library is not installed as application dependency.