Bug#332753: xlibmesa-gl-dev: cannot link OpenGL app: /usr/bin/ld: cannot find, -lGL

[Andre Heynatz <vetasana@gmx.de>]

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