10 Dec
2017
10 Dec
'17
8:37 p.m.
On 12/10/2017 03:31 PM, Paul Davis wrote:
On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <
markus.seeber(a)spectralbird.de> wrote:
That is exactly the problem with plugins. At the same time I'd say:
"Don't use these GUI librarys for plugins and do not load any plugin that exports
these symbols."
and be done with it, let offensive software die. In my eyes writing a plugin GUI
in GTK/Qt is very bad practice for exactly these reasons.
Or even better: Do not run the plugin GUI inside the DAW procces. Surely this comes with
it's own challenges as plugin developers now have to develop IPC mechanisms inside
their
plugins and a way to negotiate how the GUI process connects to the plugin DSP part etc...
.
Or go the JACK way, but for a DAW we already know that this has it's own problems.
Just employ static linking when sensible.
unortunately, several large toolkits of various types make this impossible
because they themselves use dynamic (runtime-driven) loading of shared
objects. GTK (and its dependency stack) is a particular offender there, but
I believe the same is true of Qt. You can't statically link against this
type of toolkit if your goal is to end up with a self-contained binary. the
g* stack has made a few improvements in this area in recent years, but
AFAIK it still isn't possible to build a self-contained binary. JUCE
differs from this, I believe.