On 12/10/2017 03:31 PM, Paul Davis wrote:
> On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <
> markus.seeber@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
Received on Mon Dec 11 00:15:05 2017
This archive was generated by hypermail 2.1.8 : Mon Dec 11 2017 - 00:15:05 EET