Error due GTK+3 new rdepends on libgl

Error due GTK+3 new rdepends on libgl

[Otavio Salvador]

Hello folks,

commit 3d95440b77bfe90d20c8b7a96e611b6cf2ffcb70
Author: Jussi Kukkonen <jussi.kukkonen@intel.com>
Date:   Fri Oct 9 15:20:55 2015 +0300

    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.

    Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
    Signed-off-by: Ross Burton <ross.burton@intel.com>


This includes a forced rdepends on libgl and I see no reason for 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

Re: Error due GTK+3 new rdepends on libgl

[Burton, Ross]

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

On 13 October 2015 at 22:32, Otavio Salvador <
otavio.salvador@ossystems.com.br> wrote:

> This includes a forced rdepends on libgl and I see no reason for this.
>

Mainly because gtk3-demo will link to libGL.so on startup.

It would be interesting to see what happens on platforms where libgl.so
isn't available if you remove the dependency.  If GTK+ handles that
gracefully then we can make the rdepends conditional on DISTRO_FEATURES.

Ross

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

Re: Error due GTK+3 new rdepends on libgl

[Otavio Salvador]

On Tue, Oct 13, 2015 at 6:42 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 13 October 2015 at 22:32, Otavio Salvador <otavio.salvador@ossystems.com.br> wrote:
>>
>> This includes a forced rdepends on libgl and I see no reason for this.
>
> Mainly because gtk3-demo will link to libGL.so on startup.
>
> It would be interesting to see what happens on platforms where libgl.so isn't available if you remove the dependency.  If GTK+ handles that gracefully then we can make the rdepends conditional on DISTRO_FEATURES.

I am handling it in my side, meta-fsl-arm, however I think gtk3-demo
ought to link to the library when building, no?

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

Re: Error due GTK+3 new rdepends on libgl

[Burton, Ross]

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

On 13 October 2015 at 22:44, Otavio Salvador <
otavio.salvador@ossystems.com.br> wrote:

> I am handling it in my side, meta-fsl-arm, however I think gtk3-demo
> ought to link to the library when building, no?
>

No - this is covered in the thread about this recently by Jussi.

GTK+ 3 uses libepoxy to abstract the pain of using GL.  libepoxy dlopen()'s
libGL.  Thus, no automatic dependency.

Ross

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

Re: Error due GTK+3 new rdepends on libgl

[Jussi Kukkonen]

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

On 14 October 2015 at 00:42, Burton, Ross <ross.burton@intel.com> wrote:

>
> On 13 October 2015 at 22:32, Otavio Salvador <
> otavio.salvador@ossystems.com.br> wrote:
>
>> This includes a forced rdepends on libgl and I see no reason for this.
>>
>
> Mainly because gtk3-demo will link to libGL.so on startup.
>
> It would be interesting to see what happens on platforms where libgl.so
> isn't available if you remove the dependency.  If GTK+ handles that
> gracefully then we can make the rdepends conditional on DISTRO_FEATURES.
>

If dlopening libGL.so.1 fails, gtk3-demo will not run. I'm sure it's
possible to patch it to fail gracefully (after all GL is only needed for
one demo out of many) and I would guess upstream would take that as well,
but for now I just did the minimum required to get the current dependencies
correct in the recipe.

Jussi

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

Re: Error due GTK+3 new rdepends on libgl

[Otavio Salvador]

On Wed, Oct 14, 2015 at 4:31 AM, Jussi Kukkonen
<jussi.kukkonen@intel.com> wrote:
> On 14 October 2015 at 00:42, Burton, Ross <ross.burton@intel.com> wrote:
>>
>>
>> On 13 October 2015 at 22:32, Otavio Salvador
>> <otavio.salvador@ossystems.com.br> wrote:
>>>
>>> This includes a forced rdepends on libgl and I see no reason for this.
>>
>>
>> Mainly because gtk3-demo will link to libGL.so on startup.
>>
>> It would be interesting to see what happens on platforms where libgl.so
>> isn't available if you remove the dependency.  If GTK+ handles that
>> gracefully then we can make the rdepends conditional on DISTRO_FEATURES.
>
>
> If dlopening libGL.so.1 fails, gtk3-demo will not run. I'm sure it's
> possible to patch it to fail gracefully (after all GL is only needed for one
> demo out of many) and I would guess upstream would take that as well, but
> for now I just did the minimum required to get the current dependencies
> correct in the recipe.

In worse case, it would be a RRECOMMENDS. Anyway fixing it seems the
best way to handle this IMO.

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

Re: Error due GTK+3 new rdepends on libgl

[Otavio Salvador]

On Wed, Oct 14, 2015 at 9:54 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Wed, Oct 14, 2015 at 4:31 AM, Jussi Kukkonen
> <jussi.kukkonen@intel.com> wrote:
>> On 14 October 2015 at 00:42, Burton, Ross <ross.burton@intel.com> wrote:
>>>
>>>
>>> On 13 October 2015 at 22:32, Otavio Salvador
>>> <otavio.salvador@ossystems.com.br> wrote:
>>>>
>>>> This includes a forced rdepends on libgl and I see no reason for this.
>>>
>>>
>>> Mainly because gtk3-demo will link to libGL.so on startup.
>>>
>>> It would be interesting to see what happens on platforms where libgl.so
>>> isn't available if you remove the dependency.  If GTK+ handles that
>>> gracefully then we can make the rdepends conditional on DISTRO_FEATURES.
>>
>>
>> If dlopening libGL.so.1 fails, gtk3-demo will not run. I'm sure it's
>> possible to patch it to fail gracefully (after all GL is only needed for one
>> demo out of many) and I would guess upstream would take that as well, but
>> for now I just did the minimum required to get the current dependencies
>> correct in the recipe.
>
> In worse case, it would be a RRECOMMENDS. Anyway fixing it seems the
> best way to handle this IMO.

This also breaks the generation of images using Wayland but no X11.
This fails with mesa:

configure:
        prefix:          /usr
        exec_prefix:     /usr
        libdir:          /usr/lib
        includedir:      /usr/include
        OpenGL:          yes (ES1: yes ES2: yes)
        OSMesa:          no
        DRI platform:    drm
        DRI drivers:     swrast
        DRI driver dir:  ${libdir}/dri
        GLX:             no
        EGL:             yes
        EGL platforms:   drm wayland
        EGL drivers:     builtin:egl_dri2
        llvm:            no
        Gallium:         no
        Shared libs:     yes
        Static libs:     no
        Shared-glapi:    yes
        CFLAGS:          -O2 -pipe -g -feliminate-unused-debug-types
-fno-omit-frame-pointer -Wall -std=c99
-Werror=implicit-function-declaration -Werror=missing-prototypes
-fno-strict-aliasing -fno-builtin-memcmp
        CXXFLAGS:        -O2 -pipe -g -feliminate-unused-debug-types
-fno-omit-frame-pointer -fvisibility-inlines-hidden -Wall
-fno-strict-aliasing -fno-builtin-memcmp
        Macros:          -D_GNU_SOURCE -DNDEBUG -DHAVE_XLOCALE_H
-DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN
-DHAVE_LIBDRM -DHAVE_LIBUDEV -DHAVE_ALIAS -DHAVE_MINCORE
-DMESA_EGL_NO_X11_HEADERS
        PYTHON2:         python2
        Run 'make' to build Mesa

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