OpenGL + GLUT over SSH seg faulting -

i trying run opengl+glut program on ssh x forwarding. program provides following errors, seg faults.

xlib: extension "nv-glx" missing on display "localhost:10.0".

it seems being caused because "server" computer has nvidia card telling client computer use these nvidia specific rendering functions, when client doesn't have nvidia card. googled of course, , saw many other people have had similar problems; however, solution saw suggested (https://superuser.com/questions/196838/opengl-program-not-work-with-x-forwarding) try

$ export libgl_always_indirect=1   or use nonzero value 

which did not work. don't care hardware acceleration/maintaing great performance on ssh connection. window rendering.

first things first, x11 server computer produces display output. client program running on remote computer making use of display services of server.

you right insofar, message because client (running on remote computer) executed on machine nvidia gpu. it's not gpu that's making trouble, drivers. 1 of major drawbacks of linux opengl abi (application binary interface) is, driver responsible providing system's libgl.so; if think rather ill conceived specification, since actively prevents installation of drivers multiple gpus of different vendors. (windows never had problem because of it's icd opengl driver model).

anyway, nvidia gpu's libgl.so, when connecting remote x server not run nvidia driver see, server extensions not available , hence refuse work.

so can this?

well, can install mesa3d alongside nvidia drivers; linux distributions have mechanisms in place (gentoo eselect, debian alternatives), multiple variants of api provider can installed , select 1 default.

with mesa3d installed, can use ld_preload environment variable preload mesa3d libgl.so (which located in place /usr/lib64/opengl/xorg-x11/lib/libgl.so – use linux distribution's package manager tools find, it's located; or find /usr -iname 'libgl.so*' , choose one, directory not contain nvidia) instead of system default libgl.so.

another viable method use of lxc containers, create secondary system installation mesa3d default opengl provider , when logging system via ssh you're dropped such lxc container (note given right configuration it's possible make container mere overlay on base system, of breaking out bare system still possible).

the mesa3d libgl.so happily work on remote x session. keep in mind full indirect operation has been specified opengl-2.1 not further (i.e. many functions of opengl-3 , later no glx opcodes have been defined); many extensions, (that made opengl-3 core) define glx opcodes, if you're depending on indirect opengl may have fallback those.

update:

also careful when using extensions , modern opengl functionality. functions must loaded @ runtime using glxgetprocaddress prone not being available @ all. segfault you're receiving indicates, maybe calling function pointer (loaded through glew or similar), that's not available , hence you're dereferencing invalid pointer leading crash. check, functions , extensions call present!