libgbm should be impure

[Atemu]

Issue description

Currently, libgbm (a component of mesa) is linked into applications like any other library.
Last year, mesa stopped working properly with libgbm versions other than the one produced by the same version of mesa.
This is an issue because our mesa drivers are loaded impurely (from /run/opengl-driver) while libgbm is not, causing a mismatch.

This issue prevents a commonly thought to be supported use-case of running apps from a channel different to your system's channel (i.e. system from nixos-23.05, app foo from nixos-unstable) from working as it quite honestly should.

To fix that, we need to place and load libgbm from /run/opengl-driver.

Alternatively, we could ask the mesa people to support differing libgbm versions but that's a hard sell given that we're the only distro that might run into this issue.

Alternatively, alternatively, we could make mesa pure but that might not be desirable because you couldn't run older applications on newer hardware that wasn't supported at the time then anymore. Arguably though, that isn't the case right now either.

cc @K900

[K900]

Prior art: e230a4e

[K900]

Alternatively, alternatively, we could make mesa pure but that might not be desirable because you couldn't run older applications on newer hardware that wasn't supported at the time then anymore. Arguably though, that isn't the case right now either.

Also note that this is in fact the case for most applications, as libgbm is generally only used by compositors and things that need to deal with DMA-BUF (like browsers). Most things actually work fine without it.

[SomeoneSerge]

We're possibly making a related mistake with #267247, although so far my impression has been that that's the right thing to do

[Atemu]

CUDA in general might need to be considered a driver and therefore impure.

[SomeoneSerge]

CUDA in general might need to be considered a driver and therefore impure

Yes, libcuda.so is a driver, and it normally expects a hard-coded version of the kernel module, which is why nixpkgs has been linking it impurely. The cuda_compat package (available only for jetsons and for the datacenter gpus) comes as part of the cuda toolkit (rather than part of nvidia_x11) and ships a libcuda.so compatible with the older cudatoolkit releases and the newer kernel modules (opposed to being compatible with the single revision). This is why it's tempting to try linking it directly when we can

Ultimately, I think we'll have to just test it ourselves and find out the limits

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/help-understanding-the-libgl-abi-problem-and-possible-solutions/42022/25

[Atemu]

The ground work as been laid by @K900 in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31074 and should be in the next major version of mesa

See also #338109

Once that is released and in Nixpkgs, we need some minor patches to the mesa drv to support this and then this issue can be closed.

[yshui]

just got hit by this because firefox loads libgbm via LD_LIBRARY_PATH and libEGL via /run/opengl-driver, which in turn load two different versions of libLLVM.

glad to see this is being worked on.

[K900]

This is fixed in Mesa 24.3.

[bugsbugsbux]

hi, i have a problem with quickemu continuously eating my host's memory until everything crashes. apparently (quickemu-project/quickemu#1724) this is fixed in mesa 25.2.2, but quickemu depends on qemu-10.1.2 which only depends on mesa-libgbm-25.1.0

could you help me resolve this? since nothing directly depends on mesa, i guess this must be the issue. btw, i run from nixos-25.11

[K900]

This is not the right place to discuss this and this is not the issue.