How does gstreamer handle plugins with the library suffix "-1.0.so"
Locked
How does gstreamer handle plugins with the library suffix "-1.0.so"
 
|
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 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. What's the right way to do this? Thanks Jim -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: How does gstreamer handle plugins with the library suffix "-1.0.so"
|
|
Le mar. 12 juin 2018 19:38, jimfcarroll <[hidden email]> a écrit :
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 This comment is unclear and would need clarification. What does Java have to do with C plugins ?
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.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: How does gstreamer handle plugins with the library suffix "-1.0.so"
|
|
In reply to this post by jimfcarroll
On Tue, 2018-06-12 at 15:33 -0700, jimfcarroll wrote:
> 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. > See the release notes for 1.14. The .so filename should now match the plugin name. https://gstreamer.freedesktop.org/releases/1.14/ """ The default plugin entry point has changed. This will only affect plugins that are recompiled against new GStreamer headers. Binary plugins using the old entry point will continue to work. However, plugins that are recompiled must have matching plugin names in GST_PLUGIN_DEFINE and filenames, as the plugin entry point for shared plugins is now deduced from the plugin filename. This means you can no longer have a plugin called foo living in a file called libfoobar.so or such, the plugin filename needs to match. This might cause problems with some external third party plugin modules when they get rebuilt against GStreamer 1.14. """ > 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 > 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. > > What's the right way to do this? > > Thanks > Jim > > > > > -- > Sent from: http://gstreamer-devel.966125.n4.nabble.com/ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: How does gstreamer handle plugins with the library suffix "-1.0.so"
|
|
In reply to this post by Nicolas Dufresne-5
Philippe and Nicolas,
Thanks for the responses. There is a mismatch in the expectations with the java code. I will take it up with them on that list. You can see the problem here: https://github.com/gstreamer-java/gst1-java-core/blob/v0.9.3/src/org/freedesktop/gstreamer/lowlevel/GstNative.java#L35 Notice, this value is defaulted to "%s-1.0". It's a template that forms the name of the library from the name of the plugin. In order to change the default, because it's "final static" you MUST supply the value as a -D parameter on the runtime java command line. It cannot reliably be changed programatically. However, to get gstreamer to load it at all, it can no longer be named XXXX-1.0. I will take this up with the guys over on the Java group. Thanks. Also, I'm pretty sure the only reason it works at all, since this code is also used to load native plugins that are part of the distribution, is because the lib directory ALSO contains versions of the libraries named -1.0.so, which is why I mentioned that it appears many (most?) plugin libs are named this way. For example, "ls llibgst*.so | cat" from the lib directory gives: libgstadaptivedemux-1.0.so libgstallocators-1.0.so libgstapp-1.0.so libgstaudio-1.0.so libgstbadaudio-1.0.so libgstbadvideo-1.0.so libgstbase-1.0.so libgstbasecamerabinsrc-1.0.so libgstcheck-1.0.so libgstcodecparsers-1.0.so libgstcontroller-1.0.so libgstfft-1.0.so libgstgl-1.0.so libgstinsertbin-1.0.so libgstisoff-1.0.so libgstmpegts-1.0.so libgstnet-1.0.so libgstopencv-1.0.so libgstpbutils-1.0.so libgstphotography-1.0.so libgstplayer-1.0.so libgstreamer-1.0.so libgstriff-1.0.so libgstrtp-1.0.so libgstrtsp-1.0.so libgstsdp-1.0.so libgsttag-1.0.so libgsturidownloader-1.0.so libgstvideo-1.0.so libgstwayland-1.0.so libgstwebrtc-1.0.so Note, this is a FRESH install of Ubuntu 18.04 with additional gstreamer libs added from the default package manager. I'm not sure if this is a 1.14 oversight that these libraries are still installed but I'm pretty sure it's the only reason the java API works at all. Thanks again. Jim -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: How does gstreamer handle plugins with the library suffix "-1.0.so"
|
|
Le mer. 13 juin 2018 07:27, jimfcarroll <[hidden email]> a écrit : Philippe and Nicolas, Be aware the these a libraries, not plugins. We do version on our libraries so they can be installed in parallel with 0.10 ones.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: How does gstreamer handle plugins with the library suffix "-1.0.so"
|
|
Thanks Nicolas,
Based on responses on the Java list, it appears that the code I pointed to on the java side is also used to load core gstreamer libraries and not supposed to be used for plugins. I've been misusing the method to load my own custom plugin. It's much clearer now. Thanks again. Jim -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: How does gstreamer handle plugins with the library suffix "-1.0.so"
|
|
Le mer. 13 juin 2018 09:12, jimfcarroll <[hidden email]> a écrit : Thanks Nicolas, I'm glad it's all clarified. I don't know if there is binding yet, but to load a plugin manually, there is gst_plugin_load_file() function.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |