On 05.06.2016 07:22, Lisandro Damián Nicanor Pérez Meyer wrote: > > The problem came with GLU: we didn't knew that there was no GLES-based GLU on > those archs when we made the decision, so things ported from Qt4 to Qt5 > started to FTBFS. As the problems appeared later (ie, not when we uploaded Qt5 > to the archive) and the decision was already made we decided that the real fix > would be to have a proper GLES-based GLU implementation. It is worth to note > that the amount of packages with this issue is not too big (read below). > > We actually missed to switch arm64 where GLES support is definitely the way to > go, so we will be probably filing new bugs at some point in the future > (#799113). Timo Jyrinki did the switch in Ubuntu already and could only find a > handfull of problematic packages. > > Of course if at some point we have a GLES-based GLU implementation in the > archive this will easily be fixed. For the moment and as far as I know, we > don't have such a thing. FWIW, I suspect that if something uses GLU, it's also rather likely that it uses things from desktop OpenGL which aren't available in GLES. So before anyone spends serious effort on a GLES-based GLU, I'd first make sure that there's any chance of it helping at all, e.g. by just making the glu.h header available and checking that the build of any packages in question makes it at least to the linking stage, and that the linker doesn't complain about any unresolved gl[A-Z] symbols. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Attachment:
signature.asc
Description: OpenPGP digital signature