GNOME Bugzilla – Bug 759133
glimagesink: dlopen's wrong libGLESv2 and libEGL on Raspberry Pi
Last modified: 2016-05-15 09:08:18 UTC
On the Raspberry Pi, the vendor libGLESv2.so with hardware acceleration support has for SONAME just "libGLESv2.so", and the plugin is correctly linked with this one. However, the plugin then dlopen's "libGLESv2.so.2", which, when libgles2-mesa is installed, resolves to that one, leading to: pi@raspberrypi ~ $ lsof -p 4844|grep GLES gst-launc 4844 pi mem REG 179,2 29996 48656 /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 gst-launc 4844 pi mem REG 179,2 105151 138994 /opt/vc/lib/libGLESv2.so ... and rapidly to a segfault with a corrupted gdb backtrace, which is not that trivial to investigate. The SONAME used for opening is hardcoded, and should surely be computed at configure time instead to match that of the selected GLESv2 implementation.
The problem is indeed the compatibility with mesa. To fix you need to either point LD_LIBRARY_PATH to /opt/vc/lib before the system libraries or pass --with-gles2-module-name and --with-egl-module-name pointing to /opt/vc/lib libraries. You can check which libraries have been loaded with 'info sharedlibrary' in gdb at a strategic point (say gst_gl_display_new()).
Thanks for pointing out those flags. However that's still a manual thing and although it allows "those who know" to get things right, it should imho be automated. BTW, the wording of those flags help, eg. "default: libGLESv2" gives the impression that the corresponding define would be used, although in reality different code is used. I'd think the real name of the shlib could just be extracted from the program linked with libGLESv2 when configure checks for it, it's just a matter of running "objdump -p |grep SONAME" on it. That would even give the opportunity to get rid of the "if all fails try libGLESv2.so just in case" hack. Unfortunately I don't think autoconf gives access to those temporary files, and we would need to write a new complete test macro just for this, but that sounds pretty much doable.
Maybe I am wrong but I think one of the problems (in that specific and uncommon case) is the ".so.2" in http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglcontext.c#n117 There is no such suffix in /opt/vc/lib. So whatever order you have in LD_LIBRARY_PATH it will always pick the one provided by mesa, i.e. the one in /usr/lib/arm-linux-gnueabihf/. Yann, could you tell us what comes first in the default ld search path on RPI ? If /opt/vc/lib comes first then a simple fix could be to swap [114, 117] with [119, 121] in file http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/gstglcontext.c#n114 You can check that in /etc/ld.so.conf and /etc/ld.so.conf.d/*.conf In worst case even if /opt/vc/lib try to uninstall mesa-dev, keeping mesa. (I am saying that because I know that on some distribution you won't be able to uninstall mesa without uninstalling almost everything :) ) and still apply that swap I suggested above. About looking at the lib name at configure time, it sounds a good idea, but I think one goal is to have libgstgl-1.0.so not linked with EGL and GL libs at al (not entirely sure of the feasibility though, It would require to build a vtable for EGL like it is done for GL. And also sometimes libEGL links against libGL, like on RPI).
(In reply to Julien Isorce from comment #3) > Yann, could you tell us what comes first in the default ld search path on > RPI ? If /opt/vc/lib comes first then a simple fix could be to swap [114, > 117] with [119, 121] in file > http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/ > gstglcontext.c#n114 IIRC there was some reason that the order is the way it is. Nicolas probably knows more details. I think it was for the same reason but for drivers that provide libGLESv2.so.2 but not libGLESv2.so (was it Mali?).
(In reply to Julien Isorce from comment #3) > Maybe I am wrong but I think one of the problems (in that specific and > uncommon case) is the ".so.2" in > http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/ > gstglcontext.c#n117 > There is no such suffix in /opt/vc/lib. So whatever order you have in > LD_LIBRARY_PATH it will always pick the one provided by mesa, i.e. the one > in /usr/lib/arm-linux-gnueabihf/. > > Yann, could you tell us what comes first in the default ld search path on > RPI ? /opt/vc/lib does come first (if not, ld.so would have loaded /usr/lib/libGLESv2.so, which was present from the libgles2-mesa-dev package). > If /opt/vc/lib comes first then a simple fix could be to swap [114, > 117] with [119, 121] in file > http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/ > gstglcontext.c#n114 That would only be stacking a hack atop another. The goal here is I suppose to get access to the symbols of the libGLESv2 that is already loaded in memory, playing with search path will surely work in this case, but that's still a hack and it will surely break in other cases. > You can check that in /etc/ld.so.conf and /etc/ld.so.conf.d/*.conf > In worst case even if /opt/vc/lib try to uninstall mesa-dev, keeping mesa. > (I am saying that because I know that on some distribution you won't be able > to uninstall mesa without uninstalling almost everything :) ) and still > apply that swap I suggested above. As a workaround I have deinstalled mesa, which I had only installed on the raspi by error while porting other packages. > About looking at the lib name at configure time, it sounds a good idea, but > I think one goal is to have libgstgl-1.0.so not linked with EGL and GL libs > at al (not entirely sure of the feasibility though, It would require to > build a vtable for EGL like it is done for GL. And also sometimes libEGL > links against libGL, like on RPI). You mean that would allow to compile it once for all platform variants ? We'll always get into such problems with vendors using different lib names... It would be great indeed if it was possible for dlopen to return a handle to an already-loaded lib without any risk of loading another one (or even a newer version in case the lib was upgraded between running the app and calling dlopen). In fact, glibc's RTLD_NOLOAD may be a solution for this (just guessing, still to be checked), but g_module does not appear to allow its use! Thinking about it, for other porting work I had to write (Q&D) pkgconfig files for /opt/vc stuff. Availability of such files would probably make it easier to get the proper lib name from configure.ac, even if it's only to dlopen it.
libEGL is also subject to this problem, and there the case is worse, as libegl1-mesa is required by xserver-xorg-core. Now Raspbian should probably provide an Xorg linked against /opt/vc/ (if that works at all), but at the very least they should compile it --with-egl-module-name as you noted.
The name with the ABI version are the correct one, while the name without (RPI) are incorrect. RPi GL stack is not a properly installed and symlink on the raspian distribution. (In reply to Yann Dirson from comment #6) > libEGL is also subject to this problem, and there the case is worse, as > libegl1-mesa is required by xserver-xorg-core. Now Raspbian should probably > provide an Xorg linked against /opt/vc/ (if that works at all), > but at the very least they should compile it --with-egl-module-name as you > noted. Even with Mesa, the installation offers the standard name libEGL.so.1 (with ABI). What we can commonly find, is to rename all GL/EGL/GLES library with a vendor specific names, and use symlinks to allow changing the stack. What I would suggest, is whether to add an easy hardcoded Raspbian configuration, or try and convince Raspbian maintainer to fix it.
(In reply to Nicolas Dufresne (stormer) from comment #7) > The name with the ABI version are the correct one, while the name without > (RPI) are incorrect. RPi GL stack is not a properly installed and symlink on > the raspian distribution. It's not only an installation issue, it's at least a build issue. There is no symlink because the SONAME of the lib does not include an ABI number. Now is it just a "vendor just did not bother" issue, or is it deeper, still has to be seen. > (In reply to Yann Dirson from comment #6) > > libEGL is also subject to this problem, and there the case is worse, as > > libegl1-mesa is required by xserver-xorg-core. Now Raspbian should probably > > provide an Xorg linked against /opt/vc/ (if that works at all), > > but at the very least they should compile it --with-egl-module-name as you > > noted. > > Even with Mesa, the installation offers the standard name libEGL.so.1 (with > ABI). What we can commonly find, is to rename all GL/EGL/GLES library with a > vendor specific names, and use symlinks to allow changing the stack. > > What I would suggest, is whether to add an easy hardcoded Raspbian > configuration, or try and convince Raspbian maintainer to fix it. It's not a Raspbian specific problem. For the same reason, yocto has no symlinks either. The issue is really an upstream one. IIRC Broadcom released this set of libs as opensource, but I don't know their maintainance status, should check.
So, does anyone have a better suggestion then the --with-egl/gles2-module-name configure option that we have created for the purpose of supporting non-standard installation ? If not, I'll close as won't fix.