www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - D equivalent of run-time DLLs / Plugins

reply Chris Katko <ckatko gmail.com> writes:
Hello. Dlang newbie here.

Does D support run-time loading of D modules?

Basically, I'm looking to create an application with a plugin 
interface.

I've seen a few posts, but they're dated and it's hard to keep up 
with "What is the proper way to do X" when things change rapidly. 
Last thing I want to do is retread ground when someone else 
already has a more elegant solution.

Also, are there any features to avoid that will cause problems? I 
don't plan on needing anything too fancy.

Thanks.
Feb 29 2016
next sibling parent Carsten =?UTF-8?B?QmzDvGdnZWw=?= <hans-carsten.blueggel freenet.de> writes:
On Monday, 29 February 2016 at 19:02:27 UTC, Chris Katko wrote:

 Hello. Dlang newbie here.

 Does D support run-time loading of D modules?

 Basically, I'm looking to create an application with a plugin 
 interface.

 I've seen a few posts, but they're dated and it's hard to keep 
 up with "What is the proper way to do X" when things change 
 rapidly. Last thing I want to do is retread ground when someone 
 else already has a more elegant solution.

 Also, are there any features to avoid that will cause problems? 
 I don't plan on needing anything too fancy.

 Thanks.


Sounds like You are looking for package 
https://code.dlang.org/packages/derelict-util
and adjust to Your needs.
Feb 29 2016
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 29 February 2016 at 19:02:27 UTC, Chris Katko wrote:

 Hello. Dlang newbie here.

 Does D support run-time loading of D modules?

 Basically, I'm looking to create an application with a plugin 
 interface.

 I've seen a few posts, but they're dated and it's hard to keep 
 up with "What is the proper way to do X" when things change 
 rapidly. Last thing I want to do is retread ground when someone 
 else already has a more elegant solution.

 Also, are there any features to avoid that will cause problems? 
 I don't plan on needing anything too fancy.

 Thanks.


Mike Parker's book covers the subject
https://www.packtpub.com/application-development/learning-d

That part of the book closely follows a series he wrote on 
gamedev (there's more than just that post)
http://www.gamedev.net/page/resources/_/technical/game-programming/binding-d-to-c-r3122
Feb 29 2016
parent reply Chris Katko <ckatko gmail.com> writes:
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.

 Does D support run-time loading of D modules?

 Basically, I'm looking to create an application with a plugin 
 interface.

 I've seen a few posts, but they're dated and it's hard to keep 
 up with "What is the proper way to do X" when things change 
 rapidly. Last thing I want to do is retread ground when 
 someone else already has a more elegant solution.

 Also, are there any features to avoid that will cause 
 problems? I don't plan on needing anything too fancy.

 Thanks.


 Mike Parker's book covers the subject
 https://www.packtpub.com/application-development/learning-d

 That part of the book closely follows a series he wrote on 
 gamedev (there's more than just that post)
 http://www.gamedev.net/page/resources/_/technical/game-programming/binding-d-to-c-r3122


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.
Feb 29 2016
next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 02/29/2016 02:40 PM, Chris Katko wrote:


 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.


It's the same as in C. Assuming that you have a ./libxyz.so that 
contains library_function() of type 'int library_func(int)', the 
following works:

import std.stdio;
import core.sys.linux.dlfcn;

extern(C) int library_func(int);
alias FuncType = int function(int);

int main()
{
     void * lib = dlopen("./libxyz.so", RTLD_NOW);

     if (!lib) {
         stderr.writefln("Failed to open library");
         return 1;
     }

     auto func = cast(FuncType)dlsym(lib, "library_func");

     if (!func) {
         stderr.writefln("Failed to find function");
         return 1;
     }

     writefln("Result: %s", func(10));

     return 0;
}

Ali
Feb 29 2016
prev sibling parent Carsten =?UTF-8?B?QmzDvGdnZWw=?= <hans-carsten.blueggel freenet.de> writes:
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).
Feb 29 2016