Subject: bug#49847: OpenGL applications may fail to run on foreign distributions

From: Maxim Cournoyer <[email-masked]>
Date: Wed, 04 Aug 2021 22:21:23 -0400

Hi Ludovic,

Ludovic Courtès <[email-masked]> writes:

> Hi,
>
> Maxim Cournoyer <[email-masked]> skribis:
>
>> 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!
>
> 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.

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