clutter/cogl on arm

peter green plugwash at p10link.net
Mon Jan 16 00:18:18 UTC 2012


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
* toonloop

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)
* pinpoint
* mx
* mutter
* snappy-player
* libchamplain
* ibus-client-clutter
* gnome-sushi
* gnome-shell
* gnome-games
* gnome-control-center
* 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).
* evolution
* eog-plugins
* empathy
* emerillon
* clutter-imcontext
* clutter-gtk-0.10
* clutter-gtk
* clutter-gesture
* cheese

The following source packages failed to build on armel and armhf for other
reasons
* libclutter-perl

The following source packages only produce arch all packages so no build
was performed on arm architectures.
* clutter-sharp

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
of action. 

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
days.




More information about the pkg-gnome-maintainers mailing list