clutter/cogl on arm
I brought this up previously on debian-arm but I hadn't fully ascertined the
scope of the problem at the time and I got little response. So I think it's
best to start this as a new thread with a topic that reflects the real issue
and to provide as a starting point as much information about the problem and
it's scope as I can reasonablly find.
Mesa in debian offers both gl and gles2 on debian and provides software
implementations for both on all architectures.
According to Josselin Mouette DRI based drivers support both GL and GLES
but propietry 3D drivers for NVIDIA and ATI only support GL According to
Konstantinos Margaritis propietry. The rest of this post will assume that
those statements were correct.
Recently cogl was introduced to debian being built against gles on
armel/armhf and regular gl on all other architectures. (afaict some
versions uploaded to experimental only built against cogl on armel
not armhf but I really only care about what happened in unstable)
clutter-1.0 recently started building against cogl and switched to building
against gles on both armel and armhf. Afaict this change was introduced
to unstable with the upload of clutter-1.0 1.8.0-1.
This will break any source file that tries to include both regular
gl headers and clutter/cogl headers on armel. I do not know if it
can also cause problems at link time or run time beyond those at
compile time. Any experts like to comment on that?
The following source packages* FTBFS on armel and/or armhf due to this
While this is the first incidence of this problem i've run into I
doubt it will be the only one. Especially as interest in hardware
accelerated graphics on arm increases.
The following source packages seemed to have been built successfully on at
least one out of armel or armhf recently
* rhythmbox (note: the latest version hasn't been attempted yet so I looked
at the previous version)
* lua-gtk (note: this was not build on armhf due to packages-arch-specific
and the armel buildd build was very old so I checked it locally on armel
and it built fine).
The following source packages failed to build on armel and armhf for other
The following source packages only produce arch all packages so no build
was performed on arm architectures.
Assuming the compile time problems are the only ones with this switch and given
that there currently only seems to be one package with compile time problems
caused by this I would suggest fixing that package is the most reasonable course
If you belive there are problems beyond the compile time header incompatibilities
run into by toonloop or problems in indirect reverse-depends please mention them
ASAP. If noone does so I will attempt to prepare a patch for toonloop in a few