I have nvidia-glx and nvidia-glx-dev installed from experimental, because unstable has rather old packages. I use nvidia-glx 1.0.7676-1.
[[Background info about my OpenGL development: I experiment with OpenGL 2.0 and GL SL, and would like to use nVidia extensions in a controlled manner (optional, if nVidia HW is present). So I need to switch back and forth between standard OpenGL headers and nVidia provided headers. I have seen that Mesa supports OpenGL 2.0 as well, at least GL_SHADING_LANGUAGE_VERSION is defined which I need for the 3DLabs OpenGL 2.0 only examples. ]] I have read bug report #208198 and am somewhat confused. It has become a combinatorical problem, and my head smokes. But there seems to be an easy way out: libGL.so.1 is linked to different files whether Mesa or nVidia libs are used: libGL.so.1 -> libGL.so.1.2 (Mesa SW only driver) or libGL.so.1 -> libGL.so.1.0.7676 (nVidia 76.76 driver) You create a symlink: libGL.so -> libGL.so.1.2 which assumes too much. Either it is diverted as well, which adds complexity for every new driver, or: Simply change the symlink to ,,,,,,,,,,,,,,,,,,,,,, libGL.so -> libGL.so.1 ^^^^^^^^^^^^^^^^^^^^^^ This works for both Mesa and nVidia without complex and error prone scripting. I do not know if ldconfig optimizes such symlink chains, but I think startup time is not hampered too much by that. If it were, I would rather file a bug against ldconfig to add optimization there, because having variants is not confined to OpenGL, but result of competition. This would be a great step towards allowing the new nVidia driver to enter unstable. Several versions since 71.74 have not entered unstable yet, although they seem to work. I think the bug #208198 and some automatic nVidia chip detection for the newer drivers which do not support older HW are still missing. Andre Heynatz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
