GNOME Bugzilla – Bug 498924
deprecate GST_PLUGIN_DEFINE_STATIC because it's not portable
Last modified: 2008-01-09 18:31:16 UTC
GST_PLUGIN_DEFINE_STATIC macro uses GST_GNUC_CONSTRUCTOR which is enabled only when it is compiled using gcc. MSVC users can't utiliaze this special constructor, so the static plugin does not work.
You are correct. For a number of reasons, including what you mention here, apps should not use GST_PLUGIN_DEFINE_STATIC, but should use GST_PLUGIN_DEFINE() instead, and register the plugins during initialization. This will probably be removed in 0.11, but we have to keep it around right now because of API compatibility. It might be a good idea to officially deprecate it, though.
Er, I'll just take the opportunity to decide that it should be deprecated, and ask someone to review the patch.
Created attachment 99507 [details] [review] patch
If you are going to deprecat GST_PLUGIN_DEFINE_STATIC, what is the alternative way to embed plugins in the binary file? Some people do not want their plugins to be publicly available in DLL for some reasons.
If you're not creating a plugin, don't use GST_PLUGIN_DEFINE() at all.
*** Bug 393796 has been marked as a duplicate of this bug. ***
Anyone want to go through the test suite (for -all) and remove the usages of GST_PLUGIN_DEFINE_STATIC()?
> [A]pps should not use GST_PLUGIN_DEFINE_STATIC, but should use > GST_PLUGIN_DEFINE() instead, and register the plugins during initialization. How should they register it from main()? With _gst_plugin_register_static()? If yes, maybe we should make it available under a non-private-looking name with a define?
gst_element_register() with plugin==NULL.
> gst_element_register() with plugin==NULL. Ah, right. how about adding some gst_element_register_static() and gst_type_find_register_static() #defines then. Rationale: - it's more intuitive, IMHO - gst_type_find_register() currently doesn't accept plugin == NULL, and it's a bit awkward to allow it from 0.10.16 onwards and tell people to use _register(NULL, ...) instead - they're likely to get it wrong and not update the requirements, leading to problems when run against previous GStreamer versions. If you add a new function or define and recommend to use that it's clear that they need to update the version requirements, since otherwise it won't even compile.
That's a problem. Also, I'd be a lot more comfortable keeping the current behavior, i.e., that factory->plugin is never NULL, but plugin->module might be. I think I'd be more comfortable making gst_plugin_register_static() available in the API and using that. In particular, it encourages libraries and binaries to separate their factories into GstPlugins and GstPluginDescriptions that properly describe their origin, which is good. This may be more interesting if we ever have a pipeline viewer/editor that can attach to a running program.
Done: 2008-01-09 Tim-Philipp Müller <tim at centricular dot net> * docs/gst/gstreamer-sections.txt: * gst/gst.c: (init_post): * gst/gstplugin.c: (_gst_plugin_register_static), (gst_plugin_register_static), (_gst_plugin_initialize), (gst_plugin_register_func): * gst/gstplugin.h: (GST_PLUGIN_DEFINE_STATIC): API: add gst_plugin_register_static() and deprecate GST_PLUGIN_DEFINE_STATIC, since it's not portable (#498924). Also, in _gst_plugin_register_static(), make sure to call g_thread_init() before calling GLib functions such as g_list_append() if we're not initialised yet, since that may lead to random crashes with older GSlice/GLib versions. * tests/check/gst/gstplugin.c: Adapt unit test to above changes. (For the record: the #ifndef GST_DISABLE_DEPRECATED in gstplugin.h shouldn't cause problems with the icydemux unit test in gst-plugins-good if core is released before the macro-less next -good, because the unit tests in -good are not compiled with -DGST_DISABLE_DEPRECATED, unlike the plugins themselves). > That's a problem. Also, I'd be a lot more comfortable keeping the current > behavior, i.e., that factory->plugin is never NULL, but plugin->module might > be. That's not really the current behaviour AFAICT, since 2007-05-12 David Schleef <ds@schleef.org> * gst/gst.c: Add GST_DISABLE_OPTION_PARSING, in order to disable option parsing for embedded systems. * gst/gstelementfactory.c: Allow gst_element_register() to be called with plugin==NULL. Did nobody notice that static elements were broken? got released with 0.10.13, so we can't really change it back now, can we?