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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #5 from Yann Dirson <ydirson at free.fr> ---
(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.

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