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

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

[Maxim Cournoyer]

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/

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

Hi,

Em terça-feira, 3 de agosto de 2021, às 14:33:06 -03, Maxim Cournoyer 
escreveu:
> 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.

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

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

[Maxim Cournoyer]

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

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

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> 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.

If that’s what happens, we’d have to arrange so that our Mesa doesn’t
dlopen non-Guix shared libs.

Thanks,
Ludo’.

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

[Maxim Cournoyer]

Hi Ludovic,

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

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> 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