October 2, 2017 at 08:49 #15910edechampsParticipant
I am currently evaluating NoMachine Workstation on Debian Sid (NoMachine-Workstation 5.3.12-11). I am using i3 (no desktop environment) in a virtual session on a completely headless server (it doesn’t even have X.org installed).
I have recently upgraded my system and since then it appears there are issues running applications that rely on GLX.
For example, if I try to run the QT-based ReText Markdown editor:
$ retext Could not initialize GLX Aborted
$ glxgears Error: couldn't get an RGB, Double-buffered visual
$ glxinfo name of display: :1001 Error: couldn't find RGB GLX visual or fbconfig
$ LIBGL_ALWAYS_INDIRECT=y glxinfo name of display: :1001 Error: couldn't find RGB GLX visual or fbconfig
$ ldd /usr/bin/glxinfo linux-vdso.so.1 (0x00007fffe48c0000) libGLEW.so.2.0 => /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0 (0x00007ff3d0c24000) libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007ff3d09b5000) libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007ff3d0729000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff3d0425000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007ff3d00e5000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007ff3cfed3000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff3cfb36000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff3cf7b7000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff3cf5a0000) libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007ff3cf36f000) libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007ff3cf0b9000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff3ceeb5000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff3cec98000) /lib64/ld-linux-x86-64.so.2 (0x00007ff3d10c5000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007ff3cea70000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007ff3ce86c000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007ff3ce666000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007ff3ce451000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff3ce249000)
Packages with “glx” in the name that are installed on the system: libglx-mesa0 (17.2.1-2) libglx0 (0.2.999+git20170802-5) libxcb-glx0 (1.12-1)
I also attached the output of the xdpyinfo command, which does mention the GLX extension.
Note that I am *not* looking to enable hardware acceleration using VirtualGL or anything like that. I am fine with basic software-based rendering. I just want it to work.
Attachments:October 3, 2017 at 08:16 #15919edechampsParticipant
I managed to find a workaround.
I noticed that during my Debian system upgrade the mesa packages were updated from 17.1.5-1 to 17.2.1-2. If I roll them back to 17.1.5-1 then everything works again.
This leads me to conclude that the changes between mesa 17.1.5 and mesa 17.2.1 are breaking GLX on NoMachine Workstation virtual sessions.October 3, 2017 at 09:34 #15921graywolfModerator
Thanks for reporting. Debian sid provides the latest available libraries, so it is possible. By the way we are going to investigate in order to address this issue on our side.November 21, 2017 at 09:31 #16546FerdHParticipant
The system requires libGLX_indirect.so.0 to be available. This should be a symlink to libGLX_mesa.so.0
Took me quite a while to figure out, but I now have GLX on virtual NoMachine desktops
This is what you need to do:
Make sure you have the package libglx-mesa0 installed
ln -s libGLX_mesa.so.0 libGLX_indirect.so.0November 28, 2017 at 13:43 #16736graywolfModerator
FerdH, thanks for the tip.
By the way, I’ve just updated a Sid system and that symlink looks fixed now.
glxgears runs fine.
This topic was marked as solved, you can't post.