OpenGL applications may fail to run on foreign distributions

OpenSubmitted by Maxim Cournoyer.
Details
3 participants
  • Thiago Jung Bauermann
  • Ludovic Courtès
  • Maxim Cournoyer
Owner
unassigned
Severity
normal
M
M
Maxim Cournoyer wrote on 3 Aug 19:33 +0200
(name . bug-guix)(address . bug-guix@gnu.org)
87k0l25t7x.fsf@gmail.com
Hello Guix,
I recently discovered that on systems that used another implementationof OpenGL than those provided by Mesa (such as systems using theproprietary 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 driverson these systems, I think in theory there might be issues also when mixand matching Guix's Mesa libGL along the foreign distro kernel (whichmay run Mesa but from a much older/or recent version).
I also think that it is quite surprising that graphical applicationsdistributed with Guix packs fail to be 'universal' in the way we've cometo 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.socould be loaded from the system instead.
Thanks,
Maxim
[0] https://github.com/NVIDIA/libglvnd/
T
T
Thiago Jung Bauermann wrote on 3 Aug 23:13 +0200
(address . 49847@debbugs.gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
1948377.OP2kyRLfc7@popigai
Hi,
Em terça-feira, 3 de agosto de 2021, às 14:33:06 -03, Maxim Cournoyer escreveu:
Toggle quote (4 lines)> 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
L
L
Ludovic Courtès wrote on 4 Aug 23:30 +0200
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 49847@debbugs.gnu.org)
87fsvonbir.fsf@gnu.org
Hi,
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
Toggle quote (5 lines)> 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 driverscome from a foreign distro, the application is likely to crash sooner orlater.
If that’s what happens, we’d have to arrange so that our Mesa doesn’tdlopen non-Guix shared libs.
Thanks,Ludo’.
M
M
Maxim Cournoyer wrote on 5 Aug 04:21 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 49847@debbugs.gnu.org)
87r1f8my1o.fsf@gmail.com
Hi Ludovic,
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (28 lines)> 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 theother way around; the Guix applications are hard-coded to use Mesa'slibGL.so, which has its own expectations of what DRM drivers should beavailable 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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 49847@debbugs.gnu.org