Bug#798408: Bug#797816: openscad FTBFS in armhf due to conflict declaration of headers gl3.h and glew.h
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. -- 1: Una computadora sirve: * Para tratar de dominar el mundo, un caso conocido de esto fue el de Skinet Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#798408: Bug#797816: openscad FTBFS in armhf due to conflict declaration of headers gl3.h and glew.h
On Tue, Jan 05, 2016 at 11:44:51AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > 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. 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 signature.asc Description: PGP signature
Bug#798408: Bug#797816: openscad FTBFS in armhf due to conflict declaration of headers gl3.h and glew.h
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=armel=1.2%2Bsvn1430-5=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
Re: Bug#798408: Bug#797816: openscad FTBFS in armhf due to conflict declaration of headers gl3.h and glew.h
On Tuesday 15 September 2015 19:39:26 Lisandro Damián Nicanor Pérez Meyer wrote: > On Monday 14 September 2015 10:06:54 chrysn wrote: > [snip] > > > On Wed, Sep 02, 2015 at 04:31:03PM -0300, Tiago Stürmer Daitx wrote: > > > openscad 2015.03-1+dfsg-2ubuntu1 FTBFS on armhf due to conflicting > > > headers. > > > > 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. > > Qt5 links against GLES in arm*, Desktop GL otherwise. The reason is simple: > 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. Make that armel armhf, somehow we missed arm64. We might change that though. -- ¿Qué vamos a hacer esta noche Cerebro? -Lo mismo que todas las noches Pinky... ¡¡¡tratar de conquistar el mundo!!! Pinky y Cerebro. Narf. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Re: Bug#798408: Bug#797816: openscad FTBFS in armhf due to conflict declaration of headers gl3.h and glew.h
On Monday 14 September 2015 10:06:54 chrysn wrote: [snip] > On Wed, Sep 02, 2015 at 04:31:03PM -0300, Tiago Stürmer Daitx wrote: > > openscad 2015.03-1+dfsg-2ubuntu1 FTBFS on armhf due to conflicting > > headers. > > 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. Qt5 links against GLES in arm*, Desktop GL otherwise. The reason is simple: 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. -- My favourite poem is the one that starts 'Thirty days hath September' because it actually tells you something. -- Groucho Marx Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Bug#798408: Bug#797816: openscad FTBFS in armhf due to conflict declaration of headers gl3.h and glew.h
block 797816 by 798408 thank you On Wed, Sep 02, 2015 at 04:31:03PM -0300, Tiago Stürmer Daitx wrote: > openscad 2015.03-1+dfsg-2ubuntu1 FTBFS on armhf due to conflicting headers. 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
