GNOME Bugzilla – Bug 667305
build: Add --enable-static-plugins configure argument
Last modified: 2013-04-22 23:24:22 UTC
Created attachment 204623 [details] [review] patch This will build all plugins as static libraries.
Created attachment 204638 [details] [review] patch Static linking plugins for gst-plugins-base
As I mentioned on IRC, I'm not convinced we should add such a configure argument, not only because I'm not keen on supporting this, but also because it requires a fair bit of work to stay license-compliant when distributing GStreamer statically linked, so making it too easy just seems like an invitiation, if not encouragement, to break the license.
I tried using these patches, but i am getting the following errors in gst-plugins-base/gst/adder/gstadder.c while building: In file included from /home/ace/Desktop/gstreamer_ndk_bundle/gstreamer/gst/gstelement.h:55, from /home/ace/Desktop/gstreamer_ndk_bundle/gstreamer/gst/gstbin.h:27, from /home/ace/Desktop/gstreamer_ndk_bundle/gstreamer/gst/gst.h:35, from /home/ace/Desktop/gstreamer_ndk_bundle/jni/../gst-plugins-base/gst/adder/gstadder.h:26, from /home/ace/Desktop/gstreamer_ndk_bundle/jni/../gst-plugins-base/gst/adder/gstadder.c:46: /home/ace/Desktop/gstreamer_ndk_bundle/gstreamer/gst/gstconfig.h:191:1: warning: this is the location of the previous definition /home/ace/Desktop/gstreamer_ndk_bundle/jni/../gst-plugins-base/gst/adder/gstadder.c:1327:1: error: pasting ""adder"" and "_register" does not give a valid preprocessing token /home/ace/Desktop/gstreamer_ndk_bundle/jni/../gst-plugins-base/gst/adder/gstadder.c:1327:1: error: pasting "gst_plugin_" and ""adder"" does not give a valid preprocessing token /home/ace/Desktop/gstreamer_ndk_bundle/jni/../gst-plugins-base/gst/adder/gstadder.c:1323: error: expected '=', ',', ';', 'asm' or '__attribute__' before string constant /home/ace/Desktop/gstreamer_ndk_bundle/jni/../gst-plugins-base/gst/adder/gstadder.c:1327:1: error: pasting ""adder"" and "_register" does not give a valid preprocessing token /home/ace/Desktop/gstreamer_ndk_bundle/jni/../gst-plugins-base/gst/adder/gstadder.c:1327:1: error: pasting "gst_plugin_" and ""adder"" does not give a valid preprocessing token /home/ace/Desktop/gstreamer_ndk_bundle/jni/../gst-plugins-base/gst/adder/gstadder.c:1323: error: expected '=', ',', ';', 'asm' or '__attribute__' before string constant
I have solved the problem by changing "adder" to adder (i.e. removing quotes)......I am not familiar with the GStreamer Source Code so I am not sure if what i have done is correct or not...... Following this approach......I had to change a lot of C source files for different plugins...I am still in the process of building ... will confirm as I am done with the build process.
Is there really any reason why you would want a static linked GStreamer? For all use cases I can currently imagine a self-contained GStreamer tree would be enough and wouldn't have lots of problems (like the ones mentioned by Tim).
(In reply to comment #5) > Is there really any reason why you would want a static linked GStreamer? For > all use cases I can currently imagine a self-contained GStreamer tree would be > enough and wouldn't have lots of problems (like the ones mentioned by Tim). Some mobile devices does not allow dynamic linking... And others have limitations on how many dynamic plugins you can have. Also, I am not sure I am buying the argument that because it is a bit of work required to be compliant, GStreamer should not offer it? You would only be breaking the license if you refused to provide the necessary bits in a published product, and if you cared so much about not releasing the proprietary code you would be linking against, surely you would take the proper precautions?
(In reply to comment #4) > I have solved the problem by changing "adder" to adder (i.e. removing > quotes)......I am not familiar with the GStreamer Source Code so I am not sure > if what i have done is correct or not...... > > Following this approach......I had to change a lot of C source files for > different plugins...I am still in the process of building ... will confirm as I > am done with the build process. Yes, that is the trick to this patch. In order to make use of it, all plugin-names have to be changed in that manner.
Ok, there seems to be a need for this feature. It is important that we document the license/legal implications of this and make sure that everybody is aware of them when enabling this. For the original patch, it would be good if the API would be the same for dynamic and static plugins, i.e. use the name parameter of the macro not as a string in any case. Of course this can only be done for 0.11/1.0.
> For the original patch, it would be good if the API would be the same for > dynamic and static plugins, i.e. use the name parameter of the macro not as a > string in any case. Of course this can only be done for 0.11/1.0. That is the case with this patch. It changes it for both the dynamic and static scenario. We build our GStreamer from the same source both dynamically and statically.
Håvard, did you look at using library constructors for the registration of the static plugins instead of requiring the application to manually all plugins it ever wants to use? There's some macro magic in recent glib to use the constructors in a portable way if existing, glib/gconstructor.h For 0.10 it might make sense to add a G_PLUGIN_DEFINE2() to not break API and have the non-string plugin name parameter.
Branches of everything with these changes are here: http://cgit.collabora.com/git/user/slomo/gstreamer.git/log/?h=static-plugins http://cgit.collabora.com/git/user/slomo/gst-plugins-base.git/log/?h=static-plugins http://cgit.collabora.com/git/user/slomo/gst-plugins-good.git/log/?h=static-plugins http://cgit.collabora.com/git/user/slomo/gst-plugins-ugly.git/log/?h=static-plugins http://cgit.collabora.com/git/user/slomo/gst-plugins-bad.git/log/?h=static-plugins http://cgit.collabora.com/git/user/slomo/gst-ffmpeg.git/log/?h=static-plugins http://cgit.collabora.com/git/user/slomo/gnonlin.git/log/?h=static-plugins
> Branches of everything with these changes are here: > > http://cgit.collabora.com/git/user/slomo/gstreamer.git/log/?h=static-plugins > http://cgit.collabora.com/git/user/slomo/gst-plugins-base.git/log/?h=static-plugins Just had a quick look at these. I don't entirely understand the purpose of the GST_PLUGIN_STATIC_REGISTER_FUNCTION_NAME thing in GST_PLUGIN_STATIC_REGISTER. And in the plugins, wouldn't it be better to add a global GST_PLUGIN_LIBTOOLFLAGS instead of doing + if !GST_PLUGIN_BUILD_STATIC libgstfoo_la_LIBTOOLFLAGS = --tag=disable-static + endif ? everywhere?
(In reply to comment #12) > [...] > I don't entirely understand the purpose of the > GST_PLUGIN_STATIC_REGISTER_FUNCTION_NAME thing in GST_PLUGIN_STATIC_REGISTER. Leftover from an experiment that didn't work. It's fixed now :) > And in the plugins, wouldn't it be better to add a global > GST_PLUGIN_LIBTOOLFLAGS instead of doing > + if !GST_PLUGIN_BUILD_STATIC > libgstfoo_la_LIBTOOLFLAGS = --tag=disable-static > + endif ? > > everywhere? Will do that when merging all this.
Hi Sebastian Dröge, Why all the features disappear after I use the static plugin method, while the plugins can still be probed. =================================== x264: x264enc: x264enc mad: mad: mad mp3 decoder audioflinger: audioflingersink: Android Audioflinger Sink faad: faad: AAC audio decoder staticelements: bin: Generic bin staticelements: pipeline: Pipeline object Total count: 166 plugins (161 blacklist entries not shown), 6 features ======================================= This is what I get via gst-inspect. These available features belong to the plugin in dynamic load. Thanks, TonyL
Created attachment 241563 [details] Static linking README I'm happy for this to go in provided there's an additional README that outlines some of the license/distribution issues with static linking in addition to the license. I have attached a draft document for what I have in mind roughly. Needs some fleshing out perhaps. Sebastian suggested some changes that I haven't incorporated yet.
Created attachment 241565 [details] Static linking README Some minor changes, looks good otherwise to me :) Let's put this into docs/random/README.static-linking or something like that
commit 18a7a1d06295fe602672a5ce143c88260ea93930 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Wed Oct 24 11:58:35 2012 +0200 gst: Add better support for static plugins API: GST_PLUGIN_STATIC_DECLARE() API: GST_PLUGIN_STATIC_REGISTER() Based on a patch by Håvard Graff <havard.graff@tandberg.com>. This now allows GST_PLUGIN_DEFINE() to create a static plugin if GST_PLUGIN_BUILD_STATIC is defined. The resulting plugin can be statically linked or dynamically linked during compilation but can't be dynamically loaded during runtime. Also adds GST_PLUGIN_STATIC_DECLARE() and GST_PLUGIN_STATIC_REGISTER(), which allows to register a static linked plugin easily. It is still required to manually register every single statically linked plugin from inside the application as this can't be automated in a portable way. A new configure parameter --enable-static-plugins was added that allows to build all plugins we build here as static plugins. Fixes bug #667305. (and related commits to all other modules)
commit c0faf64dff582a587075256d6da9ddea3edaa7b6 (in common) Author: Tim-Philipp Müller <tim@centricular.net> Date: Sat Apr 20 15:45:37 2013 +0100 add static linking README https://bugzilla.gnome.org/show_bug.cgi?id=667305