<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 16, 2018 at 1:07 PM jonetsu <<a href="mailto:jonetsu@teksavvy.com">jonetsu@teksavvy.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 16 Nov 2018 17:56:23 +0100<br>
Robin Gareus <<a href="mailto:robin@gareus.org" target="_blank">robin@gareus.org</a>> wrote:<br>
<br>
> Say you write a plugin that needs ffmpeg and uses the newer<br>
> libswresample2 interface, and another author writes a plugin that uses<br>
> the older libswresample1 API. Now you dynamically link both.<br>
<br>
Just a probably very stupid question.  If plugins from a manufacturer<br>
are all using the same statically-linked toolkit, then would it be<br>
possible for that manufacturer to ship their plugins with a .so of the<br>
toolkit for them to use instead of having that toolkit embedded in<br>
every single plugin binary ? </blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">this might or might not be possible, but it doesn't solve the problem(s).</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">whether gtk+2 and/or gtk+3 come with the plugin or not, you can't have them both in the same process address space (think "program instance"). </div><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">so whether or not the plugin finds a good way to provide the library to itself or not, it won't deal with collisions between libraries inside the host (DAW). <br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">characteristics of an acceptable library: no static global variables, nothing polluting the global namespace, no module loading by the library, preferably no symbols exported other than the ones that form the library API.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">very few desktop toolkits get all this right. they were written to be the toolkit for an *application*, not a blob of binary code that gets loaded into an application.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"></div><br></div></div>