Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr
Hello everyone, this is a follow-up email because while the bug was closed and OpenMW compiles (and runs) on armhf, what is rendered to the screen via OSG-3.4 is everything but pretty. The short term solution is to disable building OpenMW on armhf and rebuild any builds still online. I have more below inline... On Thu, Sep 29, 2016 at 11:36 PM, Alberto Luaces wrote: > > This is a list of facts that I know: > > - OSG "as is" does FTBFS on arm platforms. You can verify that reading > the logs for 3.4: armhf (configured for GLES2) succeeds while armel > (default configuration) breaks. > That is a pity about armel, unfortunately OSG-3.4 with only GLESv2 is useless to OpenMW, regardless of architecture. To my knowledge, OpenMW is the only application linking against OSG-3.4 at the moment. > - The decision of using GLES2 was already made by the Ubuntu team from > whom I took the patches that I told you I was going to apply > beforehand. I suppose they choose GLES2 because nowadays it is rare > to find new hardware supporting GLES1 but not GLES2, but this is mere > speculation. I do not know the reason, but I find any reason to not use standard GL dubious regardless of architecture, specifically when it comes to running Debian and/or Ubuntu on any platform. Not all arm[el|hf] have the same support but GL is the baseline while GLESv[1|2] are just subsets. Normally you would want a derivative Debian or Ubuntu to fork to a specific target GL version. I think it best to try to resolve the issue so that normal GL and not ES[1|2] is used for OSG-3.4 on all platforms since Debian is trying to be consistent across all platforms and architectures. > - On Debian and for 3.4, which depends on Qt5, the decision of using > GLES2 is also taken already for us. See their dependencies on armhf > and armel: > > https://sources.debian.net/src/qtbase-opensource-src/5.6.1%2Bdfsg-3/debian/control/#L309 > This is just plan wrong, as I stated above we should be providing a standard across the board. Qt5 should be using GL on armel/armhf. If this can't be the case, then as a workaround, we should disable building the osgQt plugin. This would allow us to build OSG-3.4 on armhf and armel with GL instead of GLESv2. > I do not know what would happen if we build OSG with GLES1 but linking > to GLES2-enabled Qt5. Does it have any chances of not breaking at > run-time? I am not sure. I tried working around this with OpenMW by disabling building armhf version of openmw-cs that makes use of osgQt. The problem is that GLESv2 render used by OSG-3.4 cannot render OpenMW very well. It doesn't crash which is surprising, and it renders stuff... just nothing anyone would want to play. :) > To me this looks like a packaging problem, because we have to decide > what dependencies we need from a global point of view, instead of in > a case-by-case basis. > It does indeed. I've tested compiling OSG-3.4 without osgQt without the armhf patches (no GLES or EGL) and it compiled just fine. I installed them on my RPi2 and then compiled OpenMW against it. It too compiled without my little work-around patch. The best part is that OpenMW runs, as expected in 1080p glory at 15fps! :) > In my opinion, that tiny patch for OpenMW on Debian looks like a good > compromise. Sadly, I tested this and while it does compile and run, it just render anything useful nor enjoyable. > Regards, > > Alberto Thanks for your comments, we really appreciate your work! :) I hope we can work through this! My recommendation is if we can't get Qt-[4|5] to commit to using GL across all platforms, that OSG-3.4 should disable building the osgQt plugin. Cheers, Bret
Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr
bret curtis writes: > With the attached patch to OSG, I can get it to compile on armhf with > GLESv1 (libgles1-mesa-dev). It disables GLESv2 however, I got an error > while they were both enabled. > > I installed the resulting packages on my RPi2 without a problem and > got OpenMW to compile on there as well. > > Was there a reason why GLESv2 as chosen over GLESv1? Are there any > other packages that depend on OSG-3.4? Can we use GLESv1 instead of > GLESv2? It would be even better if we can just use "Desktop OpenGL" on > armhf instead of the GLESvX. > Bret, when you asked about the armhf I gave my answer to the best of my knowledge. Unfortunately, I do not own any armhf device, so I cannot carry any kind of tests more than checking the build logs. Your testing is much appreciated, though. You keep mentioning "desktop OpenGL" on the armhf platform, but so far you have not shown any snippet of code not involving GLES1 or GLES2. Again to the best of my knowledge those platforms implement those GL versions accelerated, while "traditional" GL is software-emulated. This is what I have read, but I may be wrong. This is a list of facts that I know: - OSG "as is" does FTBFS on arm platforms. You can verify that reading the logs for 3.4: armhf (configured for GLES2) succeeds while armel (default configuration) breaks. - The decision of using GLES2 was already made by the Ubuntu team from whom I took the patches that I told you I was going to apply beforehand. I suppose they choose GLES2 because nowadays it is rare to find new hardware supporting GLES1 but not GLES2, but this is mere speculation. - On Debian and for 3.4, which depends on Qt5, the decision of using GLES2 is also taken already for us. See their dependencies on armhf and armel: https://sources.debian.net/src/qtbase-opensource-src/5.6.1%2Bdfsg-3/debian/control/#L309 I do not know what would happen if we build OSG with GLES1 but linking to GLES2-enabled Qt5. Does it have any chances of not breaking at run-time? I am not sure. To me this looks like a packaging problem, because we have to decide what dependencies we need from a global point of view, instead of in a case-by-case basis. In my opinion, that tiny patch for OpenMW on Debian looks like a good compromise. Regards, Alberto
Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr
With the attached patch to OSG, I can get it to compile on armhf with
GLESv1 (libgles1-mesa-dev). It disables GLESv2 however, I got an error
while they were both enabled.
I installed the resulting packages on my RPi2 without a problem and
got OpenMW to compile on there as well.
Was there a reason why GLESv2 as chosen over GLESv1? Are there any
other packages that depend on OSG-3.4? Can we use GLESv1 instead of
GLESv2? It would be even better if we can just use "Desktop OpenGL" on
armhf instead of the GLESvX.
Thoughts?
Cheers,
Bret
diff --git a/debian/control b/debian/control
index 1877a5d..ab2ba2d 100644
--- a/debian/control
+++ b/debian/control
@@ -22,6 +22,7 @@ Build-Depends: debhelper (>= 7.0.50),
freeglut3-dev [!armhf],
libgl1-mesa-dev [!armhf] | libgl-dev [!armhf],
libegl1-mesa-dev [armhf],
+ libgles1-mesa-dev [armhf],
libgles2-mesa-dev [armhf],
libxine2-dev,
libavcodec-dev,
diff --git a/debian/rules b/debian/rules
index f2113fb..408c533 100755
--- a/debian/rules
+++ b/debian/rules
@@ -66,19 +66,20 @@ LDFLAGS += -Wl,--as-needed
ifeq (armhf,$(DEB_HOST_ARCH))
EGL_LDFLAGS=$(shell pkg-config egl --libs)
-OPENGLES_LDFLAGS=$(shell pkg-config glesv2 --libs)
+OPENGLES1_LDFLAGS=$(shell pkg-config glesv1_cm --libs)
+OPENGLES2_LDFLAGS=$(shell pkg-config glesv2 --libs)
ARMHF_DEFINES=-D OSG_GL1_AVAILABLE:BOOL=OFF \
-D OSG_GL2_AVAILABLE:BOOL=OFF \
-D OSG_GL3_AVAILABLE:BOOL=OFF \
- -D OSG_GLES1_AVAILABLE:BOOL=OFF \
- -D OSG_GLES2_AVAILABLE:BOOL=ON \
+ -D OSG_GLES1_AVAILABLE:BOOL=ON \
+ -D OSG_GLES2_AVAILABLE:BOOL=OFF \
-D OSG_GL_DISPLAYLISTS_AVAILABLE:BOOL=OFF \
-D OSG_GL_MATRICES_AVAILABLE:BOOL=OFF \
-D OSG_GL_VERTEX_FUNCS_AVAILABLE:BOOL=OFF \
-D OSG_GL_VERTEX_ARRAY_FUNCS_AVAILABLE:BOOL=OFF \
-D OSG_GL_FIXED_FUNCTION_AVAILABLE:BOOL=OFF \
-D OSG_CPP_EXCEPTIONS_AVAILABLE:BOOL=OFF \
- -D OPENGL_gl_LIBRARY:STRING="${OPENGLES_LDFLAGS}" \
+ -D OPENGL_gl_LIBRARY:STRING="${OPENGLES1_LDFLAGS}" \
-D OPENGL_egl_LIBRARY:STRING="${EGL_LDFLAGS}"
endif
Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr
On Wed, Sep 28, 2016 at 9:34 AM, Alberto Luaces wrote: > Andreas Beckmann writes: > >> On 2016-09-27 12:12, bret curtis wrote: >>> To put it simply, upstream (OpenMW) has no plans to support GLESv2 at >>> this time. Since OSG-3.4 for armhf is compiled only for GLESv2, this >>> complicates things drastically and at this point I'm in over my head. >> >> IIRC, quite some packages have been removed from arm* over the last year >> that require Desktop OpenGL and don't work with "just" GLES. >> I just cannot remember (or find) concrete examples. >> So openmw is probably another RM candidate. >> > > I agree with that. As far as I know, Desktop OpenGL is not usually > hardware-accelerated on those SOC platforms, so having OpenMW available > there would be a moot point. > > Regards, > > Alberto An update: As it turns out, OpenMW uses its own osgQt and not the one that OSG ships. This is only required for building OpenMW-CS (editor/construction set) which normally is not something you would want to run on armhf (SoCs in general). We can disable this for armhf right? To be fair, I'm able to compile and run OpenMW on Raspberry Pi 2 (Raspbian) using Desktop OpenGL, 1080p @ ~30fps. To dismiss "Desktop OpenGL" on armhf, for me, not a very good idea. I managed to get OpenMW to compile on armhf using the following patch that I asked upstream to review: https://github.com/OpenMW/openmw/pull/1080 This patch manually pulls in #include from libgles1-mesa-dev. Boom, works. However Scrawl (upstream) says that adding libgles1-mesa-dev for OSG-3.4 and allowing OSG-3.4 to build with that flag turned on (currently only GLESv2 is turned on), that OSG should take care of adding #include for us that would actually fix all our problems from the OpenMW perspective. @Alberto and @Graham: Is it possible that you can add libgles1-mesa-dev [armhf] to the list of packages on OSG-3.4 and set -D OSG_GLES1_AVAILABLE:BOOL=OFF to -D OSG_GLES1_AVAILABLE:BOOL=ON please? Another question, in OpenMW's control file, how can get the openmw-cs package to build on all archs except for armhf? Does `Architecture: any [!armhf]` work? Or do I have to list all the archs? Cheers, Bret
Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr
Andreas Beckmann writes: > On 2016-09-27 12:12, bret curtis wrote: >> To put it simply, upstream (OpenMW) has no plans to support GLESv2 at >> this time. Since OSG-3.4 for armhf is compiled only for GLESv2, this >> complicates things drastically and at this point I'm in over my head. > > IIRC, quite some packages have been removed from arm* over the last year > that require Desktop OpenGL and don't work with "just" GLES. > I just cannot remember (or find) concrete examples. > So openmw is probably another RM candidate. > I agree with that. As far as I know, Desktop OpenGL is not usually hardware-accelerated on those SOC platforms, so having OpenMW available there would be a moot point. Regards, Alberto
Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr
On 2016-09-27 12:12, bret curtis wrote: > To put it simply, upstream (OpenMW) has no plans to support GLESv2 at > this time. Since OSG-3.4 for armhf is compiled only for GLESv2, this > complicates things drastically and at this point I'm in over my head. IIRC, quite some packages have been removed from arm* over the last year that require Desktop OpenGL and don't work with "just" GLES. I just cannot remember (or find) concrete examples. So openmw is probably another RM candidate. Andreas
Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr
Hello, To put it simply, upstream (OpenMW) has no plans to support GLESv2 at this time. Since OSG-3.4 for armhf is compiled only for GLESv2, this complicates things drastically and at this point I'm in over my head. If we try to switch out with , we clear up the above error but then it fails later because GLESv2 doesn't ship with support for other things defined in that are required throughout the OpenMW code base. At this point I recommend disabling OpenMW for armhf until either OpenMW supports GLESv2 (likely not to happen soon) or OSG-3.4 (find a better solution[1]) supports plain old OpenGL again and not exclusively GLESv2 on armhf. I don't understand why we can't just use plain old OpenGL on armhf and it seems like OSG-3.4 armhf support is a bit of a hack. I had OpenMW running on Raspberry Pi 2 for example just last year. Any thoughts, suggestions or other workarounds? Cheers, Bret [1] https://anonscm.debian.org/cgit/pkg-osg/openscenegraph-3.4.git/commit/?id=fa5b1385d2b82f3fec9cc6094fb3db498a36a9e3 On Sat, Sep 24, 2016 at 11:25 PM, Andreas Beckmann wrote: > Package: openmw > Version: 0.40.0-1 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > Hi, > > openmw/experimental FTBFS on armhf: > > https://buildd.debian.org/status/fetch.php?pkg=openmw&arch=armhf&ver=0.40.0-1&stamp=1474694818 > > In file included from /usr/include/osg/GL:113:0, > from /usr/include/osg/GLDefines:25, > from /usr/include/osg/GLExtensions:18, > from /usr/include/osg/State:18, > from /usr/include/osg/GraphicsContext:17, > from /usr/include/osgViewer/GraphicsWindow:17, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14: > /usr/include/GLES2/gl2.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/qt4/QtOpenGL/qgl.h:88, > from /usr/include/qt4/QtOpenGL/QGLWidget:1, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14: > /usr/include/GL/glext.h:468:19: note: previous declaration as 'typedef > ptrdiff_t GLsizeiptr' > typedef ptrdiff_t GLsizeiptr; >^~ > In file included from /usr/include/osg/GL:113:0, > from /usr/include/osg/GLDefines:25, > from /usr/include/osg/GLExtensions:18, > from /usr/include/osg/State:18, > from /usr/include/osg/GraphicsContext:17, > from /usr/include/osgViewer/GraphicsWindow:17, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14: > /usr/include/GLES2/gl2.h:70:26: error: conflicting declaration 'typedef > khronos_intptr_t GLintptr' > typedef khronos_intptr_t GLintptr; > ^~~~ > In file included from /usr/include/GL/gl.h:2055:0, > from /usr/include/qt4/QtOpenGL/qgl.h:88, > from /usr/include/qt4/QtOpenGL/QGLWidget:1, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14: > /usr/include/GL/glext.h:469:19: note: previous declaration as 'typedef > ptrdiff_t GLintptr' > typedef ptrdiff_t GLintptr; >^~~~ > > > Andreas
Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr
We know what the problem is and are working on it. Please see the following: https://anonscm.debian.org/cgit/pkg-osg/openscenegraph-3.4.git/commit/?id=fa5b1385d2b82f3fec9cc6094fb3db498a36a9e3 OSG-3.4 had the same problem until this was commited, now the package builds and OpenMW was unblocked. It too now fails and will be fixed asap. Cheers, Bret On Sat, Sep 24, 2016 at 11:25 PM, Andreas Beckmann wrote: > Package: openmw > Version: 0.40.0-1 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > Hi, > > openmw/experimental FTBFS on armhf: > > https://buildd.debian.org/status/fetch.php?pkg=openmw&arch=armhf&ver=0.40.0-1&stamp=1474694818 > > In file included from /usr/include/osg/GL:113:0, > from /usr/include/osg/GLDefines:25, > from /usr/include/osg/GLExtensions:18, > from /usr/include/osg/State:18, > from /usr/include/osg/GraphicsContext:17, > from /usr/include/osgViewer/GraphicsWindow:17, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14: > /usr/include/GLES2/gl2.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/qt4/QtOpenGL/qgl.h:88, > from /usr/include/qt4/QtOpenGL/QGLWidget:1, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14: > /usr/include/GL/glext.h:468:19: note: previous declaration as 'typedef > ptrdiff_t GLsizeiptr' > typedef ptrdiff_t GLsizeiptr; >^~ > In file included from /usr/include/osg/GL:113:0, > from /usr/include/osg/GLDefines:25, > from /usr/include/osg/GLExtensions:18, > from /usr/include/osg/State:18, > from /usr/include/osg/GraphicsContext:17, > from /usr/include/osgViewer/GraphicsWindow:17, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14: > /usr/include/GLES2/gl2.h:70:26: error: conflicting declaration 'typedef > khronos_intptr_t GLintptr' > typedef khronos_intptr_t GLintptr; > ^~~~ > In file included from /usr/include/GL/gl.h:2055:0, > from /usr/include/qt4/QtOpenGL/qgl.h:88, > from /usr/include/qt4/QtOpenGL/QGLWidget:1, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17, > from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14: > /usr/include/GL/glext.h:469:19: note: previous declaration as 'typedef > ptrdiff_t GLintptr' > typedef ptrdiff_t GLintptr; >^~~~ > > > Andreas
Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr
Package: openmw Version: 0.40.0-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Hi, openmw/experimental FTBFS on armhf: https://buildd.debian.org/status/fetch.php?pkg=openmw&arch=armhf&ver=0.40.0-1&stamp=1474694818 In file included from /usr/include/osg/GL:113:0, from /usr/include/osg/GLDefines:25, from /usr/include/osg/GLExtensions:18, from /usr/include/osg/State:18, from /usr/include/osg/GraphicsContext:17, from /usr/include/osgViewer/GraphicsWindow:17, from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19, from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14: /usr/include/GLES2/gl2.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/qt4/QtOpenGL/qgl.h:88, from /usr/include/qt4/QtOpenGL/QGLWidget:1, from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17, from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14: /usr/include/GL/glext.h:468:19: note: previous declaration as 'typedef ptrdiff_t GLsizeiptr' typedef ptrdiff_t GLsizeiptr; ^~ In file included from /usr/include/osg/GL:113:0, from /usr/include/osg/GLDefines:25, from /usr/include/osg/GLExtensions:18, from /usr/include/osg/State:18, from /usr/include/osg/GraphicsContext:17, from /usr/include/osgViewer/GraphicsWindow:17, from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19, from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14: /usr/include/GLES2/gl2.h:70:26: error: conflicting declaration 'typedef khronos_intptr_t GLintptr' typedef khronos_intptr_t GLintptr; ^~~~ In file included from /usr/include/GL/gl.h:2055:0, from /usr/include/qt4/QtOpenGL/qgl.h:88, from /usr/include/qt4/QtOpenGL/QGLWidget:1, from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17, from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14: /usr/include/GL/glext.h:469:19: note: previous declaration as 'typedef ptrdiff_t GLintptr' typedef ptrdiff_t GLintptr; ^~~~ Andreas
