After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 759133 - glimagesink: dlopen's wrong libGLESv2 and libEGL on Raspberry Pi
glimagesink: dlopen's wrong libGLESv2 and libEGL on Raspberry Pi
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.6.1
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-12-07 17:10 UTC by Yann Dirson
Modified: 2016-05-15 09:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Yann Dirson 2015-12-07 17:10:40 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.
Comment 1 Matthew Waters (ystreet00) 2015-12-07 23:06:21 UTC
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()).
Comment 2 Yann Dirson 2015-12-07 23:42:47 UTC
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.
Comment 3 Julien Isorce 2015-12-08 06:59:32 UTC
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).
Comment 4 Matthew Waters (ystreet00) 2015-12-08 07:26:50 UTC
(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?).
Comment 5 Yann Dirson 2015-12-08 07:34:26 UTC
(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.
Comment 6 Yann Dirson 2015-12-08 09:36:04 UTC
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.
Comment 7 Nicolas Dufresne (ndufresne) 2015-12-08 13:12:23 UTC
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.
Comment 8 Yann Dirson 2015-12-08 13:59:06 UTC
(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.
Comment 9 Nicolas Dufresne (ndufresne) 2016-05-01 15:13:05 UTC
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.