[Pkg-osg-devel] Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr

[bret curtis]

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 <aluaces at udc.es> 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