[PATCH 0/1] Solving the GTK+ libgl runtime dependency issue

[PATCH 0/1] Solving the GTK+ libgl runtime dependency issue

[Jussi Kukkonen]

Recap of the situation as I understand it:
* Gtk+3 works fine without any OpenGL, if GtkGLArea is not used
* When GtkGLArea is used, Gtk+ uses libepoxy which is supposed
  dlopen the correct libraries as they are needed
* Gtk+ can only handle desktop GL at the moment (GdkGLContext
  does not have a GLES profile), so epoxy ends up dlopening
  libGL.so.1

With this in mind I think the right solution is that applications that
use OpenGL in a GtkGLArea must depend on a gl implementation (currently
only libgl works).

I am sending a patch that makes gtk3-demo RDEPEND on libgl.


 - Jussi



The following changes since commit ceeb52a2544045fe8432e36307a321f6e934de49:

  linux-yocto: Update SRCREV for genericx86* BSPs (2015-10-07 00:36:47 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib jku/gtk-gl
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/gtk-gl

Jussi Kukkonen (1):
  gtk+3: gtk3-demo needs libgl

 meta/recipes-gnome/gtk+/gtk+3.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.1.4

[PATCH 1/1] gtk+3: gtk3-demo needs libgl

[Jussi Kukkonen]

The demo app uses OpenGL (within a GtkGLArea): it needs a runtime
dependency on a GL library. Current GTK+ can only handle
full GL (libGL.so.1) so RDEPEND on libgl.

Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
---
 meta/recipes-gnome/gtk+/gtk+3.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-gnome/gtk+/gtk+3.inc b/meta/recipes-gnome/gtk+/gtk+3.inc
index 558cdd7..54f84fc 100644
--- a/meta/recipes-gnome/gtk+/gtk+3.inc
+++ b/meta/recipes-gnome/gtk+/gtk+3.inc
@@ -57,7 +57,7 @@ FILES_${PN}-demo = "${bindir}/gtk3-demo \
 
 # The demo uses PNG files and mime type sniffing, so ensure that these
 # dependencies are present.
-RDEPENDS_${PN}-demo += "gdk-pixbuf-loader-png shared-mime-info"
+RDEPENDS_${PN}-demo += "gdk-pixbuf-loader-png shared-mime-info libgl"
 
 FILES_${PN} = "${bindir}/gtk-update-icon-cache-3.0 \
                ${bindir}/gtk-query-immodules-3.0 \
-- 
2.1.4

Re: [oe] [PATCH 0/1] Solving the GTK+ libgl runtime dependency issue

[Andreas Müller]

On Thu, Oct 15, 2015 at 9:42 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 15 October 2015 at 18:26, Andreas Müller <schnitzeltony@googlemail.com>
> wrote:
>
>> I have several gtk3+ applications that stopped working. E.G
>> network-manager-applet has stopped working: running
>> nm-connection-editor fails with 'Couldn't open libGL.so.1'. Same for
>> parole.
>> I grepped network-manager-applet: there is not GtkGL or GdkGL found in
>> the sources (ok - it could be the dependencies). I still get the
>> feeling something goes wrong with libepoxy. And I am quite sure that
>> I've seen both (nm-applet/parole) running with gtk3 requiring
>> libepoxy...
>>
>
> That's not good, sounds like a bug in GTK+3 - it shouldn't be initialising
> the GL code.
>
> The only bit of source that includes epoxy is gtkglarea.c.  libepoxy only
> looks up libGL.so.1 when it's invoked.
That makes it even more mysterious...
>
> What's the exact message you get, and bonus points if you can attach a gdb
> with debug symbols to get a backtrace.  Maybe something like Glade is
> instantiating every class?
>
I moved this thread to core - I sent to wrong list - sorry

Error messages are
[operator@raspberrypi2 ~]$ nm-connection-editor
Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file:
No such file or directory
[operator@raspberrypi2 ~]$ parole
Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file:
No such file or directory

Yes gdb is what I try next.

Andreas

Re: [oe] [PATCH 0/1] Solving the GTK+ libgl runtime dependency issue

[Jussi Kukkonen]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

On 15 October 2015 at 20:26, Andreas Müller <schnitzeltony@googlemail.com>
 wrote:

> On Fri, Oct 9, 2015 at 2:20 PM, Jussi Kukkonen <jussi.kukkonen@intel.com>
> wrote:
> >
> > Recap of the situation as I understand it:
> > * Gtk+3 works fine without any OpenGL, if GtkGLArea is not used
> > * When GtkGLArea is used, Gtk+ uses libepoxy which is supposed
> >   dlopen the correct libraries as they are needed
> I have several gtk3+ applications that stopped working. E.G
> network-manager-applet has stopped working: running
> nm-connection-editor fails with 'Couldn't open libGL.so.1'. Same for
> parole.
>

I just realized this  as well. Gdk initialization calls epoxy which calls
exit() if libGL.so.1 is not there. This is clearly a major problem as it
happens for all GTK+ applications, not just GL users.

As an aside the reason this didn't come up before was that something seems
to cache that initialization: If I run an application with libGL.so.1 in
place once, I can then remove the library and run the application again
successfully... Not sure what's going on there but it did hide the problem
from me.

A quick workaround is setting environment variable "GDK_GL=disabled". I'm
looking at other possible fixes now.

Jussi
​

[-- Attachment #2: Type: text/html, Size: 1814 bytes --]

Re: [oe] [PATCH 0/1] Solving the GTK+ libgl runtime dependency issue

[Andreas Müller]

On Fri, Oct 16, 2015 at 10:32 AM, Jussi Kukkonen
<jussi.kukkonen@intel.com> wrote:
> On 15 October 2015 at 20:26, Andreas Müller <schnitzeltony@googlemail.com>
> wrote:
>>
>> On Fri, Oct 9, 2015 at 2:20 PM, Jussi Kukkonen <jussi.kukkonen@intel.com>
>> wrote:
>> >
>> > Recap of the situation as I understand it:
>> > * Gtk+3 works fine without any OpenGL, if GtkGLArea is not used
>> > * When GtkGLArea is used, Gtk+ uses libepoxy which is supposed
>> >   dlopen the correct libraries as they are needed
>> I have several gtk3+ applications that stopped working. E.G
>> network-manager-applet has stopped working: running
>> nm-connection-editor fails with 'Couldn't open libGL.so.1'. Same for
>> parole.
>
>
> I just realized this  as well. Gdk initialization calls epoxy which calls
> exit() if libGL.so.1 is not there. This is clearly a major problem as it
> happens for all GTK+ applications, not just GL users.
>
> As an aside the reason this didn't come up before was that something seems
> to cache that initialization: If I run an application with libGL.so.1 in
> place once, I can then remove the library and run the application again
> successfully... Not sure what's going on there but it did hide the problem
> from me.
>
> A quick workaround is setting environment variable "GDK_GL=disabled". I'm
> looking at other possible fixes now.
>
> Jussi
1. Thanks for taking care
2. I can confirm GDK_GL=disabled makes application start properly.
Same: this setting seems to be cached also as tested with following
sequence:
| GDK_GL=disabled nm-connection-editor -> starts
| nm-connection-editor -> starts too
3. The images I had in mind which considered working did work only
because of libgl installed

Andreas

Re: [oe] [PATCH 0/1] Solving the GTK+ libgl runtime dependency issue

[Andreas Müller]

[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]

On Fri, Oct 16, 2015 at 2:27 PM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Fri, Oct 16, 2015 at 10:32 AM, Jussi Kukkonen
> <jussi.kukkonen@intel.com> wrote:
>> On 15 October 2015 at 20:26, Andreas Müller <schnitzeltony@googlemail.com>
>> wrote:
>>>
>>> On Fri, Oct 9, 2015 at 2:20 PM, Jussi Kukkonen <jussi.kukkonen@intel.com>
>>> wrote:
>>> >
>>> > Recap of the situation as I understand it:
>>> > * Gtk+3 works fine without any OpenGL, if GtkGLArea is not used
>>> > * When GtkGLArea is used, Gtk+ uses libepoxy which is supposed
>>> >   dlopen the correct libraries as they are needed
>>> I have several gtk3+ applications that stopped working. E.G
>>> network-manager-applet has stopped working: running
>>> nm-connection-editor fails with 'Couldn't open libGL.so.1'. Same for
>>> parole.
>>
>>
>> I just realized this  as well. Gdk initialization calls epoxy which calls
>> exit() if libGL.so.1 is not there. This is clearly a major problem as it
>> happens for all GTK+ applications, not just GL users.
>>
>> As an aside the reason this didn't come up before was that something seems
>> to cache that initialization: If I run an application with libGL.so.1 in
>> place once, I can then remove the library and run the application again
>> successfully... Not sure what's going on there but it did hide the problem
>> from me.
>>
>> A quick workaround is setting environment variable "GDK_GL=disabled". I'm
>> looking at other possible fixes now.
>>
>> Jussi
> 1. Thanks for taking care
> 2. I can confirm GDK_GL=disabled makes application start properly.
> Same: this setting seems to be cached also as tested with following
> sequence:
> | GDK_GL=disabled nm-connection-editor -> starts
> | nm-connection-editor -> starts too
> 3. The images I had in mind which considered working did work only
> because of libgl installed
>
I ran several remote debug sessions for nm-connection-editor with
qt-creator till I got to the point of interest. Attached you find what
I got - hope it helps.

Andreas

[-- Attachment #2: stack.tasks --]
[-- Type: application/octet-stream, Size: 2286 bytes --]

/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/libepoxy/1.3.1-r0/git/src/dispatch_common.c	250	stack	Frame #0
/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/libepoxy/1.3.1-r0/build/src/glx_generated_dispatch.c	418	stack	Frame #1
/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/libepoxy/1.3.1-r0/build/src/glx_generated_dispatch.c	590	stack	Frame #2
/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/libepoxy/1.3.1-r0/build/src/glx_generated_dispatch.c	1161	stack	Frame #3
/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/libepoxy/1.3.1-r0/build/src/glx_generated_dispatch.c	1468	stack	Frame #4
/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/gtk+3/3.16.6-r0/gtk+-3.16.6/gdk/x11/gdkglcontext-x11.c	767	stack	Frame #5
/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/gtk+3/3.16.6-r0/gtk+-3.16.6/gdk/x11/gdkglcontext-x11.c	1114	stack	Frame #6
/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/gtk+3/3.16.6-r0/gtk+-3.16.6/gdk/x11/gdkvisual-x11.c	348	stack	Frame #7
/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/gtk+3/3.16.6-r0/gtk+-3.16.6/gdk/x11/gdkscreen-x11.c	1145	stack	Frame #8
/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/gtk+3/3.16.6-r0/gtk+-3.16.6/gdk/x11/gdkdisplay-x11.c	1460	stack	Frame #9
/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/gtk+3/3.16.6-r0/gtk+-3.16.6/gdk/gdkdisplaymanager.c	463	stack	Frame #10
/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/gtk+3/3.16.6-r0/gtk+-3.16.6/gtk/gtkmain.c	1000	stack	Frame #11
/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/gtk+3/3.16.6-r0/gtk+-3.16.6/gtk/gtkmain.c	1057	stack	Frame #12
/home/superandy/tmp/oe-core-glibc/work/cortexa7t2hf-vfp-vfpv4-neon-angstrom-linux-gnueabi/network-manager-applet/1.0.4-r0/network-manager-applet-1.0.4/src/connection-editor/main.c	370	stack	Frame #13

[-- Attachment #3: nm-connection-editor.png --]
[-- Type: image/png, Size: 188825 bytes --]