Solving the GTK+ libgl runtime dependency issue
cover Solving the GTK+ libgl runtime dependency issue
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(-)
Signature · 1 line
2.1.4
PATCH 1/1 gtk+3: gtk3-demo needs libgl
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.
--- meta/recipes-gnome/gtk+/gtk+3.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
meta/recipes-gnome/gtk+/gtk+3.inc +1 -1
@@ -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 \
Signature · 1 line
2.1.4
A message that is not in the archive (sent off-list or not yet received): CALbNGRSLEKJUYXgMCdv_oB+JD++AemnvNyM8cmCqD7o26wXqeQ@mail.gmail.com
Quoted 5 lines · 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
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
Quoted 10 lines · Andreas Müller
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
Quoted 14 lines · Ross
Quoted 10 lines · Andreas Müller
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...
Quoted 5 lines
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...
Quoted 5 lines
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
Quoted 12 lines · Andreas Müller
Quoted 5 lines · 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 neededI 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
Quoted 26 lines · Jussi Kukkonen
Quoted 4 lines · Andreas Müller
Quoted 1 line · Jussi Kukkonen
Quoted 8 lines
Quoted 4 lines
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 neededI 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.
Quoted 4 lines
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
Quoted 32 lines · Andreas Müller
Quoted 26 lines · Jussi Kukkonen
Quoted 4 lines · Andreas Müller
Quoted 1 line · Jussi Kukkonen
Quoted 8 lines
Quoted 4 lines
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 neededI 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.
Quoted 4 lines
A quick workaround is setting environment variable "GDK_GL=disabled". I'm looking at other possible fixes now.
Jussi
Quoted 9 lines
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