libEGL.so and libGLESv2.so overridden by mesa

[patrick gaunt]

After installing libegl1-mesa (as part of "$ sudo apt-get install gedit" say) libEGL.so.1 and libGLESv2.so.2 appear in /usr/lib/arm-linux-gnueabihf/ and get picked up by applications loading these libraries dynamically.

The new versions don't appear to work on the raspberry pi which has its own files in /opt/vc/lib/ I think the mesa files should be removed from the package as uploaded from raspbian.

You will see that you yourselves have run into this issue here
http://www.raspbian.org/RaspbianXBMC

[peter green (plugwash)]

It's an issue i've been aware of for a while but coming up with the "least bad" soloution is tricky. AIUI we have two sets of libraries with different functionality but the same name.

The mesa packages have been in debian armel since long before the Pi existed so the raspberry pi foundation are IMO far more to blame for this mess than debian or raspbian are.

One option may be to switch cogl to using desktop opengl rather than opengl ES, that would be reasonablly debianish, would remove the library issue in this specific case and given that we don't seem like we are ever going to get an accelerated opengl es that integrates with X it would not be too damaging (performace would suck of course but it probablly does anyway).

[peter green (plugwash)]

Ok i've rebuilt clutter/cogl in raspbian against regular opengl thus breaking the dependency chain between gedit and libegl1-mesa.

I still have to do the same for raspbian jessie and deal with a few other packages.

[patrick gaunt (patrick-x)]

Hopefully this won't break more than it fixes! I would be happy to test the images before release if that would help (and you point me in the direction of some instructions)

I agree that the packages in /opt/vc/lib seem to be a bit of an afterthought by the foundation but I understand that they were provided already compiled by broadcom as closed source. So I would have thought the mesa packages in debian can only be wrappers that hand all the work on to the broadcom packages, but they don't seem to do this. As you say, this is probably because of something that broadcom didn't bother to include in their software.

When compiling mesa you can supply various specifications http://www.mesa3d.org/egl.html maybe these need tweaking for the pi differently from standard debian armel?

[peter green (plugwash)]

Notes on the changes made so I can revert them later

source Packages with sourceful changes in wheezy
clutter-1.0
cogl

source Packages binnmud in wheezy
rhythmbox
pinpoint
empathy
mutter
evolution
clutter-gesture
clutter-imcontext
clutter-gtk
ibus-client-clutter
gnome-sushi
eog-plugins
emerillon

[peter green (plugwash)]

More wheezy binnmus related to this issue:
mx
gnome-shell

[peter green (plugwash)]

For jessie:

Source packages with sourceful changes
cogl
cairo

Source packages binnmued
clutter-1.0

More binnmus for jessie to follow

[peter green (plugwash)]

more jessie binnmus

clutter-gesture
clutter-imcontext

[peter green (plugwash)]

Another sourceful change in jessie:
weston

[Diederik (didi-debian)]

Any new development on this front and/or what's the current status?

[fish (discordianfish)]

I thought this could be fixed by the order of paths in the ld.so.conf but it always prefers the one in /usr/lib/arm-linux-gnueabihf over the one in /opt/vc/lib. Anyone knows why?

Alternatively it should work to make libegl1-mesa only include symlinks to /opt/vc/lib instead of any libraries, or would that cause problems with packages depending on specific versions of the libraries?