Including Dynamically Linked Libraries in Plugins

[Marvinh]

If we use LGPL code inside our plugins we must link dynamically to avoid licensing issues, but reading from FreeAudio Clap plugins the developer used Qt framework for the UI but had to run it from a separate process which was neat since if the gui crashed the plugin would stay alive. But is this specifically for GUI libraries such as qt or do we have to create sub processes for each dll we use. Say if our plugin was a host hosting other plugins.

Code: Select all

https://github.com/free-audio/clap-plugins
1. has the advantage of being simple to deploy. 2. is more complex due to its inter-process nature. It has a few advantages:

    if the GUI crash, the audio engine does not
    the GUI can use any libraries, won't be subject to symbol or library clash etc...

We abstracted the relation between the plugin and the GUI: AbstractGui and AbstractGuiListener which lets us transparently insert proxies to support the remote model.

[Marvinh]

Or rather one extra sub process for extraneous dlls dealing with audio and one for gui since then we can use as many dlls as we like

[mystran]

It's probably just Qt not being designed for plugins. The thing with many GUI toolkits not specifically designed for plugin use is that they like to "own" the process, perhaps relying on their own event loop, perhaps having global state that doesn't play well when there might be multiple instances or perhaps even multiple plugins using the framework at the same time, they might not unload properly... and the list goes on.

You can have some of these problems with a "normal" library as well, but many well-built libraries either don't rely on "global" state or if they do, then they encapsulate it into some "library state" object that gets passed to functions, typically as the first parameter. There are reasons other than plugins to build libraries this way, but libraries built this way typically would function quite fine in a plugin.

Unfortunately though, there's no quick rule to determine which libraries are fine and which ones are not. Looking at the documentation you can usually make an educated guess though. Loading DLLs as such is not really a problem, it's just whether or not those libraries themselves can handle your use case gracefully.