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)


In file included from /usr/include/arm-linux-gnueabi/qt5/QtGui/qopengl.h:97:0,
                 from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qgl.h:39,
                 from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qglframebufferobject.h:37,
                 from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/QGLFramebufferObject:1,
                 from /«PKGBUILDDIR»/library/tulip-gui/src/GlOffscreenRenderer.cpp:26:
/usr/include/GLES3/gl3.h:69:25: error: conflicting declaration 'typedef khronos_ssize_t GLsizeiptr'
 typedef khronos_ssize_t GLsizeiptr;
                         ^
In file included from /«PKGBUILDDIR»/library/tulip-gui/src/GlOffscreenRenderer.cpp:24:0:
/usr/include/GL/glew.h:1663:19: note: previous declaration as 'typedef ptrdiff_t GLsizeiptr'
 typedef ptrdiff_t GLsizeiptr;
                   ^
In file included from /usr/include/arm-linux-gnueabi/qt5/QtGui/qopengl.h:97:0,
                 from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qgl.h:39,
                 from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qglframebufferobject.h:37,
                 from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/QGLFramebufferObject:1,
                 from /«PKGBUILDDIR»/library/tulip-gui/src/GlOffscreenRenderer.cpp:26:
/usr/include/GLES3/gl3.h:70:26: error: conflicting declaration 'typedef khronos_intptr_t GLintptr'
 typedef khronos_intptr_t GLintptr;
                          ^
In file included from /«PKGBUILDDIR»/library/tulip-gui/src/GlOffscreenRenderer.cpp:24:0:
/usr/include/GL/glew.h:1662:19: note: previous declaration as 'typedef ptrdiff_t GLintptr'
 typedef ptrdiff_t GLintptr;
                   ^

I'm not sure that's our bug.  You probably shouldn't be mixing GLES and
desktop GL that way...

Cheers,
Julien

QtOpenGL and GLew, it is *qt5/QtGui/qopengl.h* including GLES.

With all those #ifdef's, it's hard to tell at first sight if qt5opengl
on other archs is doing the same, but
https://packages.debian.org/sid/libqt5gui5 shows that arm* are the
only archs where q5 links to GLES, while it's linking to libgl1 on all
other archs.

No info about this in changelog.Debian, and no README.Debian either
for libqt5gui5.  Is that in fact a bug in qtbase-opensource-src ?

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 ?

block 797816 by 798408
thank you

as openscad upstream currently doesn't support gles, this will need
resolution from #798408. if gl and gles are mutually exclusive to that
extent, i'd prefer a solution where it is still possible to build qt
apps that use gl on armhf, for otherwise packages like openscad can't
work at all on that architecture.

best regards
chrysn

On Monday 14 September 2015 10:06:54 chrysn wrote:
[snip]
most arm* boards have native GLES support, thus benefit from using it.

As far as I remember GLEW does not supports GLES, so you basically can't use
it on arm* with Qt5.

Hope that helps, Lisandro.

On Tuesday 15 September 2015 19:39:26 Lisandro Damián Nicanor Pérez Meyer wrote:

Make that armel armhf, somehow we missed arm64. We might change that though.

Hello,

I'm getting the same issue with the "vite" package now that I have
migrated it from qt4 to qt5:

https://buildd.debian.org/status/fetch.php?pkg=vite&arch=armel&ver=1.2%2Bsvn1430-5&stamp=1450824398

In file included from /usr/include/arm-linux-gnueabi/qt5/QtGui/qopengl.h:97:0,
                 from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qgl.h:39,
                 from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/QGLWidget:1,
                 from /«BUILDDIR»/vite-1.2+svn1430/src/render/Render_opengl.hpp:56,
                 from /«BUILDDIR»/vite-1.2+svn1430/src/render/Render_opengl.cpp:67:
/usr/include/GLES3/gl3.h:69:25: error: conflicting declaration 'typedef
khronos_ssize_t GLsizeiptr'
 typedef khronos_ssize_t GLsizeiptr;

In file included from /usr/include/GL/gl.h:2055:0,
                 from /usr/include/GL/glu.h:38,
                 from /«BUILDDIR»/vite-1.2+svn1430/src/render/Render_opengl.cpp:52:
/usr/include/GL/glext.h:468:19: note: previous declaration as 'typedef ptrdiff_t GLsizeiptr'
 typedef ptrdiff_t GLsizeiptr;

vite just happens to be using both QGLWidget and GL.

Samuel

I'm tempted to remove libqt5gui5 from the list of packages that hold this bug.
It is not a bug at all from our side, arm* uses GLES (except arm64 for now)
and GLU is not ported to it.

If at some point glu gets ported to GLES and the bug still exists then we
might have a bug.

i do see qt (in whichever package) as being the "culprit" in this
situation: gl and gles being incompatible is something that at least
seems to be well-established. qt, on the other hand, used to work on
well on armhf for openscad users (#797816), which now suffer a
regression, and start suggesting to go back to qt4 where things worked
perfectly.

as far as i can judge, the choice of gles for qt builds on arm comes
from *most* arm boards having gles support (only?). unless libqt5gui5
resolves this by building a gl and a gles version (or libglew stops
conflicting against libgles, which seems to be more of an upstream than
a packaging issue, but justifies the bug being assigned to those three
packages), no non-gles qt programs can be used on those arm devices
where they would have previously worked. (of course, those never worked
on gles, but that's their individual or a glew/gles issue).

best regards
chrysn

Allow me to explain what's happening on the Qt side. It might probably happen
that things changes since I last checked out this stuff, so if you have any
tip I'll happy to read it.

This is realted to #798408, so CCing it.

First of all things from the Qt side. Qt5 relies heavily on Desktop OpenGL
*xor* GLES. Take only one of them.

On archs != arm* users normally have the choice to have a Desktop OpenGL video
card. In those cases the card's OpenGL acceleration will be used. For those
who don't have hardware acceleration software emulation will be used. Of
course, this is *sloooow*.

Now on arm* there is almost none (if any) hardware Desktop OpenGL support, but
most of the boards with hardware acceleration use GLES. So we checked with ARM
maintainers and decided to switch Qt5's builds to use GLES in those archs, so
people with the appropriate hardware would be able to use it. In other words:
instead of confining arm* users to software emulation we give them the choice
to have hardware acceleration (for those who have the proper hardware, of
course).

The problem came with GLU: we didn't knew that there was no GLES-based GLU on
those archs when we made the decision, so things ported from Qt4 to Qt5
started to FTBFS. As the problems appeared later (ie, not when we uploaded Qt5
to the archive) and the decision was already made we decided that the real fix
would be to have a proper GLES-based GLU implementation. It is worth to note
that the amount of packages with this issue is not too big (read below).

We actually missed to switch arm64 where GLES support is definitely the way to
go, so we will be probably filing new bugs at some point in the future
(#799113). Timo Jyrinki did the switch in Ubuntu already and could only find a
handfull of problematic packages.

Of course if at some point we have a GLES-based GLU implementation in the
archive this will easily be fixed. For the moment and as far as I know, we
don't have such a thing.

Hope this clears things up :)

Kinds regards, Lisandro.

FWIW, I suspect that if something uses GLU, it's also rather likely that
it uses things from desktop OpenGL which aren't available in GLES. So
before anyone spends serious effort on a GLES-based GLU, I'd first make
sure that there's any chance of it helping at all, e.g. by just making
the glu.h header available and checking that the build of any packages
in question makes it at least to the linking stage, and that the linker
doesn't complain about any unresolved gl[A-Z] symbols.

So what happens to packages that need Qt and OpenGL on the arm
architectures?

Scott K was saying in that case it is best just not to build on the arm or
try to make it work with GLES. I had a look at the offending code which is
in a single file, but have no desire to change and maintain it. So perhaps
this is the fix here?

Reading #798408 seems to justify removing mudlet from arm.

 - Craig

To the best of our experience the problem happens only with Qt+GLU, not OpenGL
itself.

[snip]

I'm afraid so, yes.

This bug still affects libavogadrolibs.

The error message on armel is

[ 97%] Building CXX object avogadro/qtplugins/cp2kinput/CMakeFiles/Cp2kInput.dir/Cp2kInputPlugin.cpp.o
cd /build/avogadrolibs-1.98.1/obj-arm-linux-gnueabi/avogadro/qtplugins/cp2kinput && /usr/bin/c++ -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_STATICPLUGIN -DQT_WIDGETS_LIB -I/build/avogadrolibs-1.98.1/obj-arm-linux-gnueabi/avogadro/qtplugins/cp2kinput -I/build/avogadrolibs-1.98.1/avogadro/qtplugins/cp2kinput -I/build/avogadrolibs-1.98.1/obj-arm-linux-gnueabi/avogadro/qtplugins/cp2kinput/Cp2kInput_autogen/include -I/build/avogadrolibs-1.98.1/avogadro -I/build/avogadrolibs-1.98.1/obj-arm-linux-gnueabi/avogadro -I/build/avogadrolibs-1.98.1 -I/build/avogadrolibs-1.98.1/obj-arm-linux-gnueabi -I/build/avogadrolibs-1.98.1/obj-arm-linux-gnueabi/avogadro/qtgui -I/buildavogadrolibs-1.98.1/obj-arm-linux-gnueabi/avogadro/io -I/build/avogadrolibs-1.98.1/obj-arm-linux-gnueabi/avogadro/core -I/build/avogadrolibs-1.98.1/obj-arm-linux-gnueabi/avogadro/molequeue -isystem /usr/include/eigen3 -isystem /usr/include/arm-linux-gnueabi/qt5 -isystem /usr/include/arm-linux-gnueabi/qt5/QtWidgets -isystem /usr/include/arm-linux-gnueabi/qt5/QtGui -isystem /usr/include/arm-linux-gnueabi/qt5/QtCore -isystem /usr/lib/arm-linux-gnueabi/qt5/mkspecs/linux-g++ -isystem /usr/include/arm-linux-gnueabi/qt5/QtNetwork -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -g -O2 -ffile-prefix-map=/build/avogadrolibs-1.98.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Wno-deprecated-declarations -std=c++17 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -MD -MT avogadro/qtplugins/cp2kinput/CMakeFiles/Cp2kInput.dir/Cp2kInputPlugin.cpp.o -MF CMakeFiles/Cp2kInput.dir/Cp2kInputPlugin.cpp.o.d -o CMakeFiles/Cp2kInput.dir/Cp2kInputPlugin.cpp.o -c /build/avogadrolibs-1.98.1/obj-arm-linux-gnueabi/avogadro/qtplugins/cp2kinput/Cp2kInputPlugin.cpp
In file included from /usr/include/arm-linux-gnueabi/qt5/QtGui/qopengl.h:105,
                 from /usr/include/arm-linux-gnueabi/qt5/QtWidgets/qopenglwidget.h:49,
                 from /usr/include/arm-linux-gnueabi/qt5/QtWidgets/QOpenGLWidget:1,
                 from /build/avogadrolibs-1.98.1/avogadro/qtopengl/glwidget.h:16,
                 from /build/avogadrolibs-1.98.1/avogadro/qtplugins/overlayaxes/overlayaxes.cpp:14:
/usr/include/GLES3/gl32.h:56:25: error: conflicting declaration 'typedef khronos_ssize_t GLsizeiptr'
   56 | typedef khronos_ssize_t GLsizeiptr;
      |                         ^~~~~~~~~~
In file included from /build/avogadrolibs-1.98.1/avogadro/rendering/avogadrogl.h:15,
                 from /build/avogadrolibs-1.98.1/avogadro/qtplugins/overlayaxes/overlayaxes.cpp:8:
/usr/include/GL/glew.h:1694:19: note: previous declaration as 'typedef ptrdiff_t GLsizeiptr'
 1694 | typedef ptrdiff_t GLsizeiptr;
      |                   ^~~~~~~~~~
/usr/include/GLES3/gl32.h:57:26: error: conflicting declaration 'typedef khronos_intptr_t GLintptr'
   57 | typedef khronos_intptr_t GLintptr;
      |                          ^~~~~~~~
/usr/include/GL/glew.h:1693:19: note: previous declaration as 'typedef ptrdiff_t GLintptr'
 1693 | typedef ptrdiff_t GLintptr;
      |                   ^~~~~~~~
/usr/include/GLES3/gl32.h:507:60: error: 'void __glewActiveTexture(GLenum)' redeclared as different kind of entity
  507 | GL_APICALL void GL_APIENTRY glActiveTexture (GLenum texture);
      |                                                            ^
/usr/include/GL/glew.h:22286:40: note: previous declaration 'void (* __glewActiveTexture)(GLenum)'
22286 | GLEW_FUN_EXPORT PFNGLACTIVETEXTUREPROC __glewActiveTexture;
      |                                        ^~~~~~~~~~~~~~~~~~~