[Bug 759133] glimagesink: dlopen's wrong libGLESv2 on Raspberry Pi

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Mon Dec 7 22:59:32 PST 2015


https://bugzilla.gnome.org/show_bug.cgi?id=759133

Julien Isorce <julien.isorce at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |julien.isorce at gmail.com

--- Comment #3 from Julien Isorce <julien.isorce at gmail.com> ---
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).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list