D equivalent of run-time DLLs / Plugins

[Carsten Blüggel via Digitalmars-d-learn]

On Monday, 29 February 2016 at 22:40:41 UTC, Chris Katko wrote:
> On Monday, 29 February 2016 at 22:12:37 UTC, jmh530 wrote:
>> On Monday, 29 February 2016 at 19:02:27 UTC, Chris Katko wrote:
>>> Hello. Dlang newbie here.
>>>
>>> ,,,
>>>
> I'm confused. Both posts appear to be for linking... D to C++ 
> DLLs. I want to link to piece of D code at run-time. I want my 
> D program to load, scan for files which are whatever 
> D-equivalent of a DLL/SO is, and load those as well. Calling 
> library functions, and having them call my core functions.

Maybe this "lifts fog of confusion": In the end, it doesn't 
matter, which source code/language (D, C, C++, Pascal etc.) a 
shared library .so/.dll was compiled from, as long as You know, 
how to access and use e.g. a function, that is compiled in as 
accessible (keyword "visibility") symbol/function name.

In C e.g., this information is in the header file, giving the 
function's declaration including intended visibility.

An example:
C source file test.c having line: int library_func(int) 
__attribute__ ((visibility ("default")));

is the base of Ali's answer (and "translated" to D, as his code 
wants to refer to this function, is):
extern(C) int library_func(int);
Read about "Linkage Attribute" in 
https://dlang.org/spec/attribute.html#linkage
The "Linkage Attribute" (it is C in Ali's example) cares about 
"Calling convention" and "Name Mangling", so one doesn't need to 
care for this anymore.

When I want to export the same functionality (of library_func) 
from D code (to be compiled in a shared object abc.so), then this 
would read like:
export int library_func(int x) { ...} // which is - as extern(D) 
is implicit- the same as
export extern(D) int library_func(int x) { ...}

$nm -D abc.so will not show exactly the name library_func, but 
some "mangled"/differing name, and compilers of each language 
(even within the same language like in C++) do name mangling in a 
different way (except in C, which has no name mangling), thus 
transporting more information as only function name.

In Your "scanning code" You refer to abc.so's function 
library_func. The D compiler knows his way to mangle and will 
find the mangĺed name.

Now back to the common sense of the 3 answers You got as of now:
Either You can do it like Ali showed for 'nix step by step with 
dlopen, dlsym...
or You can use a package dedicated to loading shared libraries in 
a portable way, like derelict-util (there may be others too, I 
don't know).
My first answer said "adjust to Your needs" and should mean: You 
have to care for the fact You mentioned Yourself, that Derelicts 
purpose is to bind to extern(C) functions, but You want to bind 
to extern(D) functions, so You have to adapt based on e.g. 
derelict-util code this 1 point and a little bit more, You have 
to do anyway, and You are done.

AS newbie, You may not know who replied to You:
Ali is the one from http://ddili.org/ders/d.en/index.html
I warmly recommend reading to You (I learned D from this (many 
thanks to Ali and TDPL myself).