[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-core] [PATCH 0/1] Solving the GTK+ libgl runtime dependency issue

[Andreas Müller]

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 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...

Andreas

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

[Burton, Ross]

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.

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?

Ross

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 --]