On 12/10/2017 03:31 PM, Paul Davis wrote: > On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber < > markus.see...@spectralbird.de> wrote: > >> >> 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. >
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. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
