[LV2] Dynamic loading for Windows plugins

JP Cimalando jp at cimalando.eu
Tue May 30 07:32:59 PDT 2017


On Tue, 30 May 2017 15:59:37 +0200
Robin Gareus <robin at gareus.org> wrote:

> On 05/30/2017 03:38 PM, JP Cimalando wrote:
> > Hello!
> > 
> > When I build some of my test plugins for MS Windows, I am in a
> > troublesome situation when I try to load them in Carla.
> > I cannot ship DLL dependencies of my plugin in the bundle.  
> 
> Plugins are supposed to be self-contained and not have any external
> dependencies. This basically means statically linking them.
> 
> The reasoning here is the to avoid conflicts. Plugin A may depend on
> libXYZ DLL version1 and Plugin B on the a different version of the
> same lib. API/ABI conflicts are worse on Windows because the runtime
> linker uses ordinals. Also hide all symbols and only expose the
> entry-point (MSVC does hide symbols by default, mingw/gcc needs
> -fvisibility-hidden)
> 
> Have a look at other plugins-standards: VSTs are statically linked for
> the same reason.
> 
> The only other option is to have the plugin dynamically load the
> shared library (from a fixed location) LoadLibrary() or dlopen()

Ok, your reasoning against dynamic libraries makes sense and I
understand it. I trust your word that dll introduce conflicts of
symbols. Using dlopen() will not result in conflicts, because one says
explicitly what library it wants the symbol from, correct?

I'll redirect my winpthread issue to mingw-w64, and for the rest I
will fall back on dlopen just like you have suggested. It is a
possibility I have thought of before, not pleasing nor elegant but a
solution nonetheless.
Thanks.

> ciao,
> robin
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.lv2plug.in
> http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in



More information about the Devel mailing list