How does gstreamer handle plugins with the library suffix "-1.0.so"

[Nicolas Dufresne]

Le mar. 12 juin 2018 19:38, jimfcarroll <jimfcarroll at gmail.com> a écrit :

>
> Hello,
>
> I started another thread but have my problem narrowed down to the name of
> the plugin library.
>
> Under 1.8.3 my plugin library was named libgstbreakout-1.0.so. This worked
> fine. The very same code built against 1.14.0 results in the same library
> but the plugin no loner loads unless I change the name of the library to
> libgstbreakout.so.
>
> I can see in the code why this is happening. For both gst-inspect-1.0 and
> gst-launch-1.0 I get something like the following using GST_DEBUG=:*7
>
> gstpluginloader.c:719:do_plugin_load: Plugin scanner loading file
> /tmp/libgstbreakout-1.0.so. tag 2
> gstplugin.c:760:_priv_gst_plugin_load_file_for_registry: attempt to load
> plugin "/tmp/libgstbreakout-1.0.so"
> gstplugin.c:811:_priv_gst_plugin_load_file_for_registry: Could not find
> symbol 'gst_plugin_breakout_1_get_desc', falling back to gst_plugin_desc
> gstplugin.c:818:_priv_gst_plugin_load_file_for_registry: Could not find
> plugin entry point in "/tmp/libgstbreakout-1.0.so"
>
> The function extract_symname is confusing the '.' in 1.0 with the '.'
> before
> .so and assumes the name of the plugin implied by the file is breakout_1
> (it
> also converts all '-'s to '_').
>
> How is it that many (most?) plugins are named libgstXXXXXX-1.0.so. This is
>

None of the plugins are name like this in GStreamer itself.

EXPECTED in the Java API. As a matter of fact, you need to bend over
> backward every time you run your program if it's not by adding template
> strings as a -D parameter on the command line.
>

This comment is unclear and would need clarification. What does Java have
to do with C plugins ?


> What's the right way to do this?
>

Feel free to propose an improvement to the parser if you feel that
versioning your plugin is needed. The truth is that this is useless since
plugins are placed in a folder that is already versionned for you,
gstreamer-1.0/. The loader still support plugins built against older
GStreamer header. But since 1.14, and this is noted in the release note,
plugins shared object and plugin name must match and is used to construct
the uniquely named C entry point for that plugin. We wanted this so that we
can have static and dynamic plugins originating from the same build,
assuming you want PIC for both. While porting GStreamer, I only found very
few places were this was difficult, and we extended the symbol generator as
needed. Notably, there is support for shared object named by the Python
build tool.


> Thanks
> Jim
>
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20180612/159ba997/attachment.html>