GNU bug report logs - #49847
OpenGL applications may fail to run on foreign distributions

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 49847 in the body.
You can then email your comments to 49847 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: bug-guix <bug-guix <at> gnu.org>
Subject: OpenGL applications may fail to run on foreign distributions
Date: Tue, 03 Aug 2021 13:33:06 -0400

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/

Message #8 received at 49847 <at> debbugs.gnu.org (full text, mbox):

From: Thiago Jung Bauermann <bauermann <at> kolabnow.com>
To: 49847 <at> debbugs.gnu.org
Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#49847: OpenGL applications may fail to run on foreign
 distributions
Date: Tue, 03 Aug 2021 18:13:46 -0300

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

Message #11 received at 49847 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 49847 <at> debbugs.gnu.org
Subject: Re: bug#49847: OpenGL applications may fail to run on foreign
 distributions
Date: Wed, 04 Aug 2021 23:30:20 +0200

Hi,

Maxim Cournoyer <maxim.cournoyer <at> 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’.

Message #14 received at 49847 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 49847 <at> debbugs.gnu.org
Subject: Re: bug#49847: OpenGL applications may fail to run on foreign
 distributions
Date: Wed, 04 Aug 2021 22:21:23 -0400

Hi Ludovic,

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

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer <at> 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

Message #19 received at 49847-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Thiago Jung Bauermann <bauermann <at> kolabnow.com>
Cc: 49847-done <at> debbugs.gnu.org
Subject: Re: bug#49847: OpenGL applications may fail to run on foreign
 distributions
Date: Mon, 07 Aug 2023 23:57:00 -0400

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.