After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 498924 - deprecate GST_PLUGIN_DEFINE_STATIC because it's not portable
deprecate GST_PLUGIN_DEFINE_STATIC because it's not portable
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Windows
: Normal minor
: 0.10.16
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 393796 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-11-22 08:30 UTC by Kwang Yul Seo
Modified: 2008-01-09 18:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (1.67 KB, patch)
2007-11-22 23:41 UTC, David Schleef
committed Details | Review

Description Kwang Yul Seo 2007-11-22 08:30:46 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.
Comment 1 David Schleef 2007-11-22 23:25:56 UTC
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.
Comment 2 David Schleef 2007-11-22 23:27:33 UTC
Er, I'll just take the opportunity to decide that it should be deprecated, and ask someone to review the patch.
Comment 3 David Schleef 2007-11-22 23:41:19 UTC
Created attachment 99507 [details] [review]
patch
Comment 4 Kwang Yul Seo 2007-11-23 02:18:04 UTC
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.
Comment 5 David Schleef 2007-11-25 10:48:09 UTC
If you're not creating a plugin, don't use GST_PLUGIN_DEFINE() at all.
Comment 6 Tim-Philipp Müller 2007-12-16 20:04:41 UTC
*** Bug 393796 has been marked as a duplicate of this bug. ***
Comment 7 David Schleef 2007-12-18 00:31:49 UTC
Anyone want to go through the test suite (for -all) and remove the usages of GST_PLUGIN_DEFINE_STATIC()?
Comment 8 Tim-Philipp Müller 2007-12-20 09:43:45 UTC
> [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?

Comment 9 David Schleef 2007-12-20 18:49:24 UTC
gst_element_register() with plugin==NULL.
Comment 10 Tim-Philipp Müller 2007-12-21 22:42:08 UTC
> 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.


Comment 11 David Schleef 2007-12-22 04:59:35 UTC
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.
Comment 12 Tim-Philipp Müller 2008-01-09 18:31:16 UTC
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?