Building several dynamic libraries with one shared GC

[NonNull]

On Sunday, 12 September 2021 at 18:56:50 UTC, Ali Çehreli wrote:
> All initialization functions of the plugins were called 
> automatically in my D test environment and all plugins were 
> usable. The trouble started when the main library was being 
> used in a foreign environment (something like Python loading 
> Python loading C++ library loading our D library): Although the 
> initialization function of the main library was being called, 
> the 'shared static this' functions of the plugins were not 
> being called.
>
> (I tried dlopen after guessing intelligently the name of the 
> 'shared static this' function (not obvious); it was not 
> satisfactory and I don't remember exactly why not.)
>
> Later I learned, this could be because merely loading a plugin 
> might not be enough, and perhaps the main library might have to 
> use a feature of the library as well:
>
>   https://forum.dlang.org/post/sdb5jb$2rk3$1@digitalmars.com
>
[...]
>
> > If several plugins are built by different third parties, each
> dynamic
> > library will have its own GC and copy of druntime right now.
>
> Like the user 'frame', I don't think that's the case.


I hope you're right about this last. Not sure how static versus 
dynamic linking affects it. ldc2 seems to default to dynamic 
linking for phobos and have druntime in a dynamic library too. 
[Not clear what DMD does with druntime when it dynamically links 
to phobos.] In that ideal situation you seem to be right. Not 
sure how a plugin can be distributed as an executable only (to 
those without a D compiler installed) without static linking and 
then what? I have a mess to sort out.
Any info or suggestions?