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

[Alberto Luaces]

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