Linux dmd has a core.runtime.Runtime.loadLibrary linkage problem

[Rambutan]

On Saturday, 10 October 2026 at 15:06:40 UTC, Jordi Sayol wrote:
> I think this might help:
>
> $ dmd -defaultlib=libphobos2.so main.d
>

Oh no! The simplest explanation that this compiles is that D 
runtime is now in libphobos2.so and so will be shared with a 
dynamic library compiled with the same option and that 
core.runtime.Runtime.loadLibrary is specialized to this situation 
only.

I found this exact situation is here,

https://dlang.org/articles/dll-linux.html#dso10

and notice it does not use core.runtime.Runtime.loadLibrary but 
just core.sys.posix.dlfcn.dlopen and unloading similarly does not 
use core.runtime.Runtime.unloadLibrary. Not needing those means D 
runtime is in libphobos2.so and shared.

So what does core.runtime.Runtime.loadLibrary do if it loads a 
statically linked dynamic library built with dmd? Does it work as 
documented and integrate the D runtime in the dynamic library 
with the dynamically linked D runtime of the loading program? I 
suspect it does not. I'd be happy to be wrong.

This situation seems to be a can of worms. Worse, what if the 
dynamic library is built with a different compiler with dynamic 
linking (to a different instance of libphobos) or static linking. 
I imagine none of this works.

So I want to stick with static linking all round and use 
Runtime.loadLibrary and Runtime.unloadLibrary to reconcile two 
statically linked instances of D runtime, exactly as I did 
successfully with gdc.

Is my linkage problem a sign that dmd cannot do this?