Hey,

Okay, so indeed, clutter-gst does not depend explicitly on GL and has been relying on clutter to provide this for a very long time. I'm interested to know why it breaks now, could you cat your clutter-1.0.pc (which version of Clutter are you using?) (it should have a dependency on gl of some kind).

I'm a bit reluctant to duplicate the code to detect the libGL from Clutter's configure.ac but I guess there might not be an other solution.

In the mean time, we are looking at exposing what clutter-gst needs from GL in Clutter/Cogl so we can just get rid of the direct dependency.

what's changed is that Cogl stopped depending on GL in the pkg-config when it started dlopening libGL.

these are the requirements of Cogl 1.7.7 on my system:

requires= cairo >= 1.10 gdk-pixbuf-2.0 >= 2.0 libdrm x11 xext xfixes >= 3 xdamage xcomposite >= 0.4 glib-2.0

this is obviously correct, given that Cogl can use libGL or libGLES at runtime.

clutter-gst should have started depending on libGL as soon as it started using the API directly. :-)

I understand that cogl does not expose it, but clutter-glx-1.0.pc is still having "gl" in the list of deps, at least here. I thought that was not going to change.

But sure, clutter-gst should have linked against it, just wanted to understand what changed.

Ok, to mitigate the breaking, I've committed a tiny patch that should solve this case. It's not ideal, but that workaround should hold until we can rid of the direct call (and as I don't want to bump clutter-gst dep on cogl/clutter) just for
that, it's likely to stay there for the case when link against clutter >= 1.4 but < 1.8.

I'm leaving this bug open until the work to conditionally use cogl_renderer_get_n_fragment_texture_units() is done.

commit c50263f81c233fbbf93f464848384de98787ae66
Author: Damien Lespiau <damien.lespiau@intel.com>
Date:   Tue Aug 30 16:48:31 2011 +0100

    build: Link against -lGL when we know it's safe to
    
    We are using a gl call (glGetIntergerv). However, detecting wich GL
    headers and library to use is getting impossible (as nowedays, cogl even
    has a runtime selection of which library should be dlopened, so it could
    be either one of flavours of the GLES1 DSO or the GLES2 DSO, or the Big
    GL one).
    
    So, really, we should not have any direct GL call in clutter-gst. The
    solution is coming, but in the mean time, just link against -lGL when
    it's safe to assume so.

Fixed it properly and now, when compiling with Cogl 1.8.0, clutter-gst does not use direct GL calls anymore. Will be in 1.4.0

commit c369b5bb7bfb557ce92bacc34810b8afe320cc60
Author: Damien Lespiau <damien.lespiau@intel.com>
Date:   Tue Sep 27 14:42:41 2011 +0100

    refactoring: Do not depend on any GL symbol
    
    Since Cogl 1.8.0 we can use cogl_renderer_get_n_fragment_texture_units()
    to know the number of texture image units available for fragment
    shaders and we can thus avoid using the direct GL call glGetIntegerv and
    linking against libGL.
    
    This does not work on OS X though as we can't get the CoglContext out of
    the ClutterBackend in that case. Make sure to special case this.
    
    Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=657225