Bug#798408: [arm] libgles2-mesa-dev and libglew-dev disagree over GLsizeiptr
On Tue, Sep 08, 2015 at 11:44:21PM +0200, Julien Cristau wrote:
> On Tue, Sep 8, 2015 at 23:11:53 +0200, Yann Dirson wrote:
>
> > Package: libgles2-mesa-dev, libglew-dev
> > Version: 10.5.7-1, 1.10.0-3
> > Severity: important
> >
> > The 2 buildd attempts of tulip 4.7.0 on armel and armhf both failed,
> > starting with the following type conflicts, and openscad hits a
> > similar problem.
> >
> > https://bugs.debian.org/793137
> > https://bugs.debian.org/797816
> >
> > libglew-dev and libgles2-mesa-dev were the same in both builds (I'm
> > puzzled that arnold does not use an uptodate mesa versions, BTW)
> >
> I'm not sure that's our bug. You probably shouldn't be mixing GLES and
> desktop GL that way...
What seems to have happenned is that while libqt4-opengl links to
libgl1 on all archs, for Qt5 things changed for armel and armhf.
So it does look like this is a Qt5 issue after all: looking that the
package's build-dep, there do not seem to be any arm-specific
discrepancy - but all archs pull both libgl-dev and libgles2-dev.
OTOH, looking at the logs, the armel build does check for varions
versions of "GL ES" (look for that specific string), while the amd64
build does not.
Using GLES on ARM looks like an upstream behaviour, and it may make
sense as ARM is essentially an embedded platform. But then do we want
to restrict ARM to GLES, as we ship libgl1 for ARM as well, and other
archs are also used in embedded space.
Don't we need separate GL and GLES builds of Qt5, for all platforms ?
Or is it simply a bug that Qt5 headers propagate the selected
implementation to the includer source file ?
Reply to: