OpenGL applications may fail to run on foreign distributions

Hello Guix,

I recently discovered that on systems that used another implementation

of OpenGL than those provided by Mesa (such as systems using the

proprietary nvidia or AMD drivers), the OpenGL application would crash,

sometimes even requiring a reboot of the host system to recover!

While the issue could be dismissed due to the use of proprietary drivers

on these systems, I think in theory there might be issues also when mix

and matching Guix's Mesa libGL along the foreign distro kernel (which

may run Mesa but from a much older/or recent version).

I also think that it is quite surprising that graphical applications

distributed with Guix packs fail to be 'universal' in the way we've come

to know them for CLI applications.

It appears this issue may have a solution in enabling libglvnd [0]

support in our Mesa so that the GPU hardware vendor provided libGL.so

could be loaded from the system instead.

Thanks,

Maxim

[0] https://github.com/NVIDIA/libglvnd/

Hi,

Em terça-feira, 3 de agosto de 2021, às 14:33:06 -03, Maxim Cournoyer

escreveu:

As some additional information, the first version of the patch to update

Mesa provided in issue 49339 enabled libglvnd, and there’s some discussion

about it in the ensuing messages.

The Mesa updat patch that was committed doesn’t enable libglvnd, and it was

decided to address that change separately.

--

Thanks,

Thiago

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Ouch. Isn’t it similar to the problem with libc’s Name Service Switch

(info "(guix) Application Setup"):

If the nscd is not running, then [applications] perform the name

lookup by themselves, by loading the name lookup services into their

own address space and running it. These name lookup services—the

‘libnss_*.so’ files—are ‘dlopen’’d, but they may come from the host

system’s C library, rather than from the C library the application is

linked against (the C library coming from Guix).

And this is where the problem is: if your application is linked

against Guix’s C library (say, glibc 2.24) and tries to load NSS plugins

from another C library (say, ‘libnss_mdns.so’ for glibc 2.22), it will

likely crash or have its name lookups fail unexpectedly.

That is, Mesa can dlopen “drivers” (shared libs), and if these drivers

come from a foreign distro, the application is likely to crash sooner or

later.

If that’s what happens, we’d have to arrange so that our Mesa doesn’t

dlopen non-Guix shared libs.

Thanks,

Ludo’.

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

I'm no expert on the matter (yet :-)) , but I think it's more like the

other way around; the Guix applications are hard-coded to use Mesa's

libGL.so, which has its own expectations of what DRM drivers should be

available from the host system's kernel, or features they provides.

When someone uses another OpenGL implementation than Mesa's own,

apparently all hell may break loose.

Maxim

Hello,

With even nvidia going with free drivers (sadly not free firmware

blobs), I think we can put this issue to rest, at least for now.

--

Thanks,

Maxim