Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let command line util peaq load the plugin statically #29

Open
wants to merge 3 commits into
base: develop
Choose a base branch
from

Conversation

martinholters
Copy link
Member

Another excerpt from #24 thanks to @mincequi.

It should be noted that this causes a significant relative increase of the executable size (more than 4 times, depending on architecture), but it's still quite small, so should be ok. Alternatively, a compile-time option to select between dynamic and static linking might make sense.

Comment on lines 157 to +165
peaq = gst_element_factory_make ("peaq", "peaq");
if (!peaq) {
puts ("Error: peaq element could not be instantiated - is the plugin installed correctly?");
puts ("Warning: peaq plugin is not installed - registering statically");
GST_PLUGIN_STATIC_REGISTER(peaq);
}

peaq = gst_element_factory_make ("peaq", "peaq");
if (!peaq) {
puts ("Error: peaq element could not be instantiated");
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe unconditionally doing GST_PLUGIN_STATIC_REGISTER(peaq) is better? The only benefit of first trying to load the plugin dynamically seems to be that one could swap out the plugin for another version/implementation without modifying the executable. But that seem rather niche. OTOH, one could fall in the trap of updating the executable but not realizing that an outdated plugin is lingering somewhere. Opinion on that, @mincequi?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @martinholters,
well it depends, if you plan to re-use your plugin system-wide. But my assumption is: the gstreamer element is only supposed to be used within that tool and therefore no system-wide installation is needed.
In general i prefer statically linked stuff nowadays for easier library handling (installing shared libraries by bypassing the package manager is a mess).
Just my two cents ;)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, either way, installation of the plugin (in a suitable location) would be optional. Actually, building it would be optional. And that's good, because I agree that most users won't deal with the plugin directly, but just use the executable. But if the plugin is built and installed, should it then be used by the executable, although it is statically linked anyway? I see no benefit in that. Or is there any problem if the executable invokes GST_PLUGIN_STATIC_REGISTER although the plugin is available dynamically? I'll try and see if anything can be made to break with an unconditional GST_PLUGIN_STATIC_REGISTER...

Maybe a compile-time setting would be nice:

  • Option 1: Basically the status quo before this PR. Plugin and (slim) executable are built, plugin needs to be installed for executable to work.
  • Option 2: No separate plugin is built, instead it is linked statically to and registered by the executable. No installation required.

But that might just not be worth it. Will need to ponder this a bit...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants