Bug#663684: libGL.so/libGL.so.1 diversions are causing issues in libgtkglext1 programs with nvidia drivers

[Andreas Beckmann]

affects 663684 + src:glx-alternatives
reassign 663684 libgtkglext1 1.2.0-2
retitle 663684 libgtkglext1: libgdkglext-x11-1.0.so.0 dlopens libGL.so instead of libGL.so.1
thanks

Hi,

I just tested a bit more and reassign this bug to libgtkglext1.

Applications that use libgdkglext and OpenGL fail to run if libGL.so 
is not found on the system. As test program I use coolwave from the 
examples directory of the gtkglext package.

    $ ./coolwave

    (coolwave:4216): GdkGLExt-WARNING **: Cannot open \u0007

    (coolwave:4216): GdkGLExt-WARNING **: Cannot open `\x99Y\u0001
    Sorry, glPolygonOffset() is not supported by this renderer.

Hmm, wrong. And why does it output some random strings?
The problem is just libgl1-mesa-dev not being installed.
Which should not be neccessary if we just want to run some prebuilt 
binary. libgtkglext1 and libgl1-mesa-glx are installed, of course.

    $ mkdir /tmp/HACK
    $ ln -s /usr/lib/x86_64-linux-gnu/libGL.so.1 /tmp/HACK/libGL.so
    $ LD_LIBRARY_PATH=/tmp/HACK ./coolwave

Now the application runs fine.

The segfault with libgl1-mesa-dev and nvidia-glx installed would be
solved by fixing the above problem, i.e. just dlopen(libGL.so.1)
instead of dlopen(libGL.so) in libgtkglext1.

This is what happens if the optimized nvidia libs are used:

* the application (./coolwave) was linked with -lGL, so libGL.so.1 
  (which resolves to the optimized nvidia one) is automatically loaded 
  when the app is run
* later libgtkglext1 does dlopen(libGL.so) which resolves to a 
  different file (the one from mesa, which is fine for linking apps 
  without picking up any unportable proprietary symbols), is opened,
  too, and now there are two different copies of all the libGL symbols, 
  which get used in an insane mixed way and cause a segfault somehow

If libGL.so and libGL.so.1 resolve to the same file dlopen() will 
notice this and not load a second set of the same symbols.
You can also reproduce the segfault by just copying libGL.so:

    $ mkdir /tmp/HACK2
    $ cp /usr/lib/x86_64-linux-gnu/libGL.so.1 /tmp/HACK2/libGL.so
    $ LD_LIBRARY_PATH=/tmp/HACK2 ./coolwave
    Segmentation fault

So always open a library by its SONAME. It's a library, not a plugin!

gdk/x11/gdkglquery-x11.c uses g_module_build_path(),
g_module_open() which seem to be intended for plug-ins:
http://developer.gnome.org/glib/2.28/glib-Dynamic-Loading-of-Modules.html

Andreas