GLX doesn’t work (NoMachine Workstation, Debian Sid)

[edechamps]

Hi,

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:

1. xdpyinfo.txt

[edechamps]

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.

[graywolf]

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.

[FerdH]

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

cd /usr/lib/x86_64-linux-gnu/

ln -s libGLX_mesa.so.0 libGLX_indirect.so.0

 

[graywolf]

FerdH, thanks for the tip.
By the way, I’ve just updated a Sid system and that symlink looks fixed now.
glxgears runs fine.

[Author]

Posts