Re: GL/gl.h, Qt5 and arm: FTBFS
Thank you all for your fast replies! -- You don’t marry someone you can live with – you marry the person who you cannot live without. Anonymous 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. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: GL/gl.h, Qt5 and arm: FTBFS
Hi Lisandro, On Mon, Mar 24, 2014 at 03:10:25PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! I'm trying to find a solution for the FTBFS of qantenna on arm* [0][1] > that fits the best to everyone. This issue seems to be very similar to a > older > thread "including both GL/gl.h and cogl/cogl.h fails on armel and armhf" [2], > but I failed to see how that was resolved. > The FTBFSs are due to conflicting declarations for GLdouble, GLsizeiptr and > GLintptr. > Basically the problem might boild down to the fact that Qt5 is built using > es2 > instead of the "desktop" opengl which, to the best of my knowledge, it's > standard OpenGL 2.0. > These are the possible solutions I think could be taken: > a) Switch Qt5 to use "desktop" OpenGL on arm*. I have tested this on > harris.d.o and works OK. As a pro, it means that other apps will not have > porting issues like this. As a con, it might mean that all the OpenGL stuff > will be done by software though, am I correct? Correct. It is rare to find accelerated OpenGL drivers for ARM; almost all the drivers out there, particularly for recent hardware, will be GLES2 instead. This means that any reasonably GL-intensive app is going to be unusable, particularly on armel. FWIW, in Ubuntu not only is Qt built for GLES2 on armhf, we are also looking at making a GLES2 build of Qt available on x86 - because for the mobile sector, regardless of architecture, GLES2 is the relevant standard that third-party drivers will be built to. I don't think it makes sense to build Qt for OpenGL on arm. > b) (supossing it's possible) provide es2 versions of mesa-common-dev, libglu1- > mesa-dev et al. and build against that on arm* Not really possible. GLU depends on GL, not GLES2. In theory it could be ported, but this has not been done AFAIK. > d) (also supossing it's possible) do not consider the FTBFS not RC (or allow > it's transition even if it's RC) until a better fix could be done. The way to address this is to ask for the old arm binaries to be removed from the archive, via a bug report against ftp.debian.org, with the explanation that qantenna is not supported on GLES2 architectures. This is a perfectly reasonable thing to do under the circumstances. Particularly given that qantenna has always required GLU, and is unsupportable now because GLU is not usable with Qt5 on arm*, I think this is the right thing to do. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: GL/gl.h, Qt5 and arm: FTBFS
This problem has been seen before in Qt4, where Debian briefly tried using GLES2 on arm* with 4.7.3 then changed back, but Ubuntu kept using it, failed build example: https://launchpad.net/ubuntu/+source/openscenegraph/3.2.0~rc1-4/+build/5615979 The changelogs note that GLES was used, but not why. In Qt4, changing between GL and GLES breaks ABI (#632602); I don't know if this is also the case in Qt5 (which would require a libqt5opengl5 -> libqt5opengl5a transition). -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: GL/gl.h, Qt5 and arm: FTBFS
On Mon, Mar 24, 2014 at 15:10:25 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! I'm trying to find a solution for the FTBFS of qantenna on arm* [0][1] > that fits the best to everyone. This issue seems to be very similar to a > older > thread "including both GL/gl.h and cogl/cogl.h fails on armel and armhf" [2], > but I failed to see how that was resolved. > As far as I can tell, http://patch-tracker.debian.org/patch/series/view/toonloop/2.2.0-1/0004-fix_arm.patch should have solved it. > The FTBFSs are due to conflicting declarations for GLdouble, GLsizeiptr and > GLintptr. > > Basically the problem might boild down to the fact that Qt5 is built using > es2 > instead of the "desktop" opengl which, to the best of my knowledge, it's > standard OpenGL 2.0. > > These are the possible solutions I think could be taken: > > a) Switch Qt5 to use "desktop" OpenGL on arm*. I have tested this on > harris.d.o and works OK. As a pro, it means that other apps will not have > porting issues like this. As a con, it might mean that all the OpenGL stuff > will be done by software though, am I correct? > Sounds about right. > b) (supossing it's possible) provide es2 versions of mesa-common-dev, libglu1- > mesa-dev et al. and build against that on arm* > > d) (also supossing it's possible) do not consider the FTBFS not RC (or allow > it's transition even if it's RC) until a better fix could be done. > > Please note that I did not include "porting the app" because, as I understand > it, there is no es2-enabled GLU available, or at least on Debian. > > I'm inclined for option a, but maybe you can provide alternative solutions. > As > a fallback (if it's possible at all) I would take option d, but that might be > needed for other apps in the no-so-distant future, when we will start to see > massive porting from Qt4 to Qt5. > I'd very much like to avoid b. The GLU spec (http://www.opengl.org/registry/doc/glu1.3.pdf) seems very much tied to old OpenGL. I didn't think GLU was still a thing used by any modern toolkit/app, though, so I'm surprised "you get to choose between GLU and Qt5" is a problem. Cheers, Julien signature.asc Description: Digital signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
