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
