Fix Gtk+3 initialization without GLX

Following patch should fix the issue of Gtk+3 applications exiting when started in systems without libGL.so.1. The issue needs to be solved with upstreams (epoxy, possibly Gtk) in future releases but for 2.0 this should do it.

This patch does not change the advice to application recipes: If the application uses OpenGL in GLArea, it should RDEPEND on libgl.

Jussi

The following changes since commit 556c0ea92eb32ddb9c9a5e30a74b2ca24ac69c68:

lib/oe/image.py: Fix dependency handling for compressed types (2015-10-14 18:08:37 +0300)

are available in the git repository at:

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

Jussi Kukkonen (1):
gtk+3: Do not try to initialize GL without libgl

 meta/recipes-gnome/gtk+/gtk+3.inc                  |  6 ++-
 ...Do-not-try-to-initialize-GL-without-libGL.patch | 60 ++++++++++++++++++++++
 meta/recipes-gnome/gtk+/gtk+3_3.16.6.bb            |  1 +
 3 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-gnome/gtk+/gtk+3/Do-not-try-to-initialize-GL-without-libGL.patch

2.1.4

Gdk initialization ends up calling epoxy GLX api, which calls exit() if libGL.so.1 is not present. In practice this prevents all GTK+ applications from starting if GLX is not present.

If opengl and x11 distro features are set, make gtk+3 RDEPEND on libgl. If opengl and x11 distro features are not set, use #ifdef to prevent the GL initialization.

Also make gtk3-demo only RRECOMMEND libgl: it can now start without libgl (but trying to run the glarea demo will exit the application).

[YOCTO #8529]

---
 meta/recipes-gnome/gtk+/gtk+3.inc                  |  6 ++-
 ...Do-not-try-to-initialize-GL-without-libGL.patch | 60 ++++++++++++++++++++++
 meta/recipes-gnome/gtk+/gtk+3_3.16.6.bb            |  1 +
 3 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-gnome/gtk+/gtk+3/Do-not-try-to-initialize-GL-without-libGL.patch

index 54f84fc..37e3934 100644
@@ -32,9 +32,11 @@ EXTRA_OECONF += " \
 "
 
 PACKAGECONFIG ??= "${@bb.utils.contains("DISTRO_FEATURES", "x11", "x11", "", d)} \
+                   ${@bb.utils.contains("DISTRO_FEATURES", "opengl x11", "glx", "", d)} \
                    ${@bb.utils.contains("DISTRO_FEATURES", "wayland", "wayland", "", d)}"
 
 PACKAGECONFIG[x11] = "--enable-x11-backend,--disable-x11-backend,at-spi2-atk fontconfig libx11 libxext libxcursor libxi libxdamage libxrandr libxrender libxcomposite libxfixes"
+PACKAGECONFIG[glx] = "--enable-glx,--disable-glx,,libgl"
 PACKAGECONFIG[wayland] = "--enable-wayland-backend,--disable-wayland-backend,wayland libxkbcommon virtual/mesa"
 
 do_install_append() {

@@ -57,7 +59,9 @@ 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 libgl"
+RDEPENDS_${PN}-demo += "gdk-pixbuf-loader-png shared-mime-info"
+# The GLArea demo will exit without libgl
+RRECOMMENDS_${PN}-demo = "libgl"
 
 FILES_${PN} = "${bindir}/gtk-update-icon-cache-3.0 \
                ${bindir}/gtk-query-immodules-3.0 \

index 1d736a4..381e607 100644
@@ -5,6 +5,7 @@ MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
 SRC_URI = "http://ftp.gnome.org/pub/gnome/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar.xz \
            file://hardcoded_libtool.patch \
            file://Dont-force-csd.patch \
+           file://Do-not-try-to-initialize-GL-without-libGL.patch \
           "
 
 SRC_URI[md5sum] = "fc59e5c8b5a4585b60623dd708df400b"

2.1.4

This adds a RDEPENDS of libgl to libgtk3, so the explicit RDEPENDS on gtk3-demo isn't required. As GTK+ explicitly checks for GLX at startup I guess you want to remove the explicit RDEPENDS on gtk3-demo and the advice that applications should rdepend on libgl?

Ross

The -demo RDEPENDS was now RRECOMMENDS but otherwise I guess that sounds correct for now: I imagine the gtk RDEPENDS will disappear once this is properly fixed upstream.

Thanks, I'll wait a moment for any other comments and send V2,

Jussi

Agreed; thanks for addressing this.

Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750