Note, after this failure, it deadlocks too.

If I do a similar hack found for RPi it works.

http://pastebin.com/vNHpLeh4

Just using NULL as the module does not work in your case either?

Also note the ANDROID case in gst_gl_context_egl_get_proc_address().


The Khronos spec says:
> eglGetProcAddress may be queried for all GL and EGL extension functions.

I would understand that as: it is expected to return useful values for all GL extension functions too. However we're using it for non-extension functions too, which is probably the main problem here.

I wonder how cogl handles all this?

Interesting comment, in cogl-winsys-egl.c

/* eglGetProcAddress doesn't support fetching core API so we need to
     get that separately with GModule */

Then they use a non-NULL module. In their configure.ac file they detect each GL library and set the GL SO name into a per-API unique name. They assume GL is in the library path, it's supposed to be for RPi, not sure why we hardcoded the path. They only case they use NULL is for Windows and OSX, using big GL.

They have a in_code boolean added to their get_proc_address() method, though imho we could also use a null-check and fallback. The plus side, is that it guaranties that you don't load big-GL symbols when doing gles, as they can be different.

Sounds like a sensible approach to me. Get the names of the different libGLES DSOs for the different available versions, and then dlopen() the one for the selected GLES API version to get the symbols.

And also do this for a) RPi and b) desktop GL too for consistency.


Want to work on that?

Don't wait on me for that one, we where using that for testing only, as eglglessink was the GL sink that behaved the best. I really want to wrap the V4L2 allocator work first.

Can we at least commit the patch from comment 2 ?

Then for a cleaner solution, I've started looking into it after reading the comments of this bug but do we really want to detect the library names at configure time like cogl does?

(In reply to comment #7)
> Can we at least commit the patch from comment 2 ?
> 
> Then for a cleaner solution, I've started looking into it after reading the
> comments of this bug but do we really want to detect the library names at
> configure time like cogl does?

I think so, though I haven't deeply looked into the cogl implementation. For sure we need to load the library by names, otherwise we risk loading the wrong symbols, then these name in the most common case should be relative, and only in very particular case shall be absolute (not even sure for RPi it has to be absolute).

Any reason you think this might not be a good approach ?

I can confirm hardcoding the full path is definitely not needed on the RPi :)

About the approach to get libnames, I think it indeed can be done at configure time but I don't really feel confident with working on our current configure.ac, I'm really not familiar enough with it :(

(In reply to comment #9)
> I can confirm hardcoding the full path is definitely not needed on the RPi :)
> 
> About the approach to get libnames, I think it indeed can be done at configure
> time but I don't really feel confident with working on our current
> configure.ac, I'm really not familiar enough with it :(

Ah I see, it's ok, I'm really busy with v4l2 right now, but I'll try to find time to do that part, or Julien can have a look ?

Created attachment 275502 [details] [review]
gl: no need to provide full lib path to load symbols

Hey thx all of you for those investigations and tests. I have no time to implement the way you suggested but at least we can push the solution #2.
Let me know if this patch works for you.

Going back to RPI project about LXDE without GL tomorrow :)

Review of attachment 275502 [details] [review]:

I'll test this on my platform today.

::: gst-libs/gst/gl/gstglcontext.c
@@ +420,2 @@
+  if (!module_egl) {
+    module_egl = g_module_open ("libEGL.so", G_MODULE_BIND_LAZY);

I think it should be libEGL.so.1, libEGL.so is usually shipped in dev packages.

@@ +439,3 @@
+    const gchar *name = NULL;
+#if GST_GL_HAVE_GLES2
+    name = "libGLESv2.so";

libGLESv2.so.2 for the same reason

Comment on attachment 275502 [details] [review]
gl: no need to provide full lib path to load symbols

With minor changes to use version in libname.

https://bug728753.bugzilla-attachments.gnome.org/attachment.cgi?id=275502

Not every platform uses .so and Android for example has libGLESv2.so and libEGL.so. You just broke Android and iOS at least :P

Can we please revert this until someone can implement a proper fix?

Note that cogl gets this completely wrong too

For ios, the module will not load, and we will fallback to NULL (which is what was there before). For Android, if there is no libGLESv2.so.2, then it will also fallback to NULL like before. It's an unfortunate trial and error, but should be that bad.

Though, looking at it again, we should probably make this default proc_address method smarter, first by having decent default for LIBNAME per platform (ifdef define blocks + configure params at the top I'd say).

Then, we should decide what to try at run-time. Load EGL when runtime API is big GL would be a bit unfortunate if there is to implementation of base gl* method.

Finally, subclass like EGL one, should always check the prefix, and chain up it's call to default get_proc is not in the egl namespace.

I'll work on this tomorrow

This hopefully fixes it once and for all in all cases

commit cad1bb32c8dc34290524e029cb27a930eb84fa78
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Thu May 1 14:36:54 2014 +0200

    gl: Try harder to load symbols from the correct place
    
    This commit makes the loading of the GModules threadsafe, and
    always first tries to load the symbol for the GL library that
    is selected for the current context. Only then it falls back
    to looking into the current module (NULL), and only as a last
    resort the context specific function (e.g. eglGetProcAddress())
    is called.
    
    Also add configure parameters to select the names of the library
    modules instead of using the defaults, and let the defaults be
    independent of the G_MODULE_SUFFIX.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=728753