www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dynamic Library Support for D

reply "Jeroen Bollen" <jbinero gmail.com> writes:
Currently D has a very poor support for creating and loading 
dynamic libraries. It requires a bunch of code while other 
languages like C just allow you to create it as you would create 
a static library.

A problem here seems to be that D wants to integrate as much as 
possible with other languages, resulting in very poor support for 
integrating with it's own language.

I understand that the problem here is that the libraries get 
saved as .so or .dll, which should also linkable with other, 
non-D, applications, meaning the runtime cannot initialize on 
it's own.

Why isn't there a D-specific format for dynamic libraries, that 
just shares the garbage collector with the main application, and 
thus only allow you to link it with D programs, and that way make 
it way easier to write a dynamic library in D.

I guess the only reason this doesn't exist is because it'll take 
a lot of work?
Jan 02 2014
next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 2 January 2014 at 18:22:46 UTC, Jeroen Bollen wrote:

 Currently D has a very poor support for creating and loading 
 dynamic libraries. It requires a bunch of code while other 
 languages like C just allow you to create it as you would 
 create a static library.

 A problem here seems to be that D wants to integrate as much as 
 possible with other languages, resulting in very poor support 
 for integrating with it's own language.

 I understand that the problem here is that the libraries get 
 saved as .so or .dll, which should also linkable with other, 
 non-D, applications, meaning the runtime cannot initialize on 
 it's own.

 Why isn't there a D-specific format for dynamic libraries, that 
 just shares the garbage collector with the main application, 
 and thus only allow you to link it with D programs, and that 
 way make it way easier to write a dynamic library in D.

 I guess the only reason this doesn't exist is because it'll 
 take a lot of work?


There is one such format, it's called DDL 
(http://dsource.org/projects/ddl) and it dates back from the 
ancient D1 civilization.
It just seems nobody has ported it to D2 yet.
Jan 02 2014
prev sibling next sibling parent Martin Nowak <code dawg.eu> writes:
On 01/02/2014 07:22 PM, Jeroen Bollen wrote:

 Currently D has a very poor support for creating and loading dynamic
 libraries. It requires a bunch of code while other languages like C just
 allow you to create it as you would create a static library.

 A problem here seems to be that D wants to integrate as much as possible
 with other languages, resulting in very poor support for integrating
 with it's own language.


There are plans to make it much simpler.
http://dconf.org/2013/talks/nowak.html

 I understand that the problem here is that the libraries get saved as
 .so or .dll, which should also linkable with other, non-D, applications,
 meaning the runtime cannot initialize on it's own.


The runtime just needs to become a .so or .dll itself.


 Why isn't there a D-specific format for dynamic libraries, that just
 shares the garbage collector with the main application, and thus only
 allow you to link it with D programs, and that way make it way easier to
 write a dynamic library in D.


It's a good idea to integrate with existing technologies and it's rather 
less effort than creating our own infrastructure.


 I guess the only reason this doesn't exist is because it'll take a lot
 of work?
Jan 02 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
It looks actually pretty capable with current 2.064.2 to me:

[dicebot fog ~]$ cat lib.d
void foo(int x)
{
     import std.stdio;
     writefln("got %s in shared lib", x);
}
[dicebot fog ~]$ cat test.d
import lib : foo;
import core.runtime : Runtime;
import core.sys.posix.dlfcn : dlsym;
import std.exception : enforce;

void main()
{
     auto handler = Runtime.loadLibrary("./lib.so");
     scope(exit) Runtime.unloadLibrary(handler);
     enforce(handler);
     auto func = cast(void function(int)) dlsym(handler, 
foo.mangleof.ptr);
     enforce(func);
     func(42);
}
[dicebot fog ~]$ dmd -shared -fPIC -defaultlib=libphobos2.so lib.d
[dicebot fog ~]$ dmd -L-ldl -defaultlib=libphobos2.so -run test.d
got 42 in shared lib
Jan 02 2014
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 2 January 2014 at 19:33:38 UTC, Dicebot wrote:

 [dicebot fog ~]$ dmd -shared -fPIC -defaultlib=libphobos2.so


I believe it also works if you don't put a default lib on the .so 
at all iff loaded by D - it finds the symbols it needs in the 
main program.

But it is also a bit of a pain to use on Windows, mainly because 
you have to do your own DllMain. I think this should be 
automated, or at least in a mixin template for easy use. With a 
windows dll, I'm not sure if the gcs are shared but they work.
Jan 02 2014
prev sibling parent "Jeroen Bollen" <jbinero gmail.com> writes:
On Thursday, 2 January 2014 at 19:33:38 UTC, Dicebot wrote:

 It looks actually pretty capable with current 2.064.2 to me:

 [dicebot fog ~]$ cat lib.d
 void foo(int x)
 {
     import std.stdio;
     writefln("got %s in shared lib", x);
 }
 [dicebot fog ~]$ cat test.d
 import lib : foo;
 import core.runtime : Runtime;
 import core.sys.posix.dlfcn : dlsym;
 import std.exception : enforce;

 void main()
 {
     auto handler = Runtime.loadLibrary("./lib.so");
     scope(exit) Runtime.unloadLibrary(handler);
     enforce(handler);
     auto func = cast(void function(int)) dlsym(handler, 
 foo.mangleof.ptr);
     enforce(func);
     func(42);
 }
 [dicebot fog ~]$ dmd -shared -fPIC -defaultlib=libphobos2.so 
 lib.d
 [dicebot fog ~]$ dmd -L-ldl -defaultlib=libphobos2.so -run 
 test.d
 got 42 in shared lib


That's not cross-platform though.
Jan 02 2014
prev sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 02.01.2014 19:22, schrieb Jeroen Bollen:

 Currently D has a very poor support for creating and loading dynamic
 libraries. It requires a bunch of code while other languages like C just
 allow you to create it as you would create a static library.

 A problem here seems to be that D wants to integrate as much as possible
 with other languages, resulting in very poor support for integrating
 with it's own language.

 I understand that the problem here is that the libraries get saved as
 .so or .dll, which should also linkable with other, non-D, applications,
 meaning the runtime cannot initialize on it's own.

 Why isn't there a D-specific format for dynamic libraries, that just
 shares the garbage collector with the main application, and thus only
 allow you to link it with D programs, and that way make it way easier to
 write a dynamic library in D.

 I guess the only reason this doesn't exist is because it'll take a lot
 of work?


See http://wiki.dlang.org/DIP45
I've been pushing for propper DLL support for a while. But it has not 
been important enough to be put on the roadmap yet. After the last thing 
I heard DLL support (and therefor shared library support) will be put on 
the roadmap of 2.066.

Kind Regards
Benjamin Thaut
Jan 02 2014
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Thursday, 2 January 2014 at 20:49:32 UTC, Benjamin Thaut wrote:

 See http://wiki.dlang.org/DIP45
 I've been pushing for propper DLL support for a while. But it 
 has not been important enough to be put on the roadmap yet. 
 After the last thing I heard DLL support (and therefor shared 
 library support) will be put on the roadmap of 2.066.

 Kind Regards
 Benjamin Thaut


If you're also interested in runtime loading, it would be nice to 
have more feedback to this pull request:

   https://github.com/D-Programming-Language/druntime/pull/617
Jan 02 2014
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 02.01.2014 21:54, schrieb Jakob Ovrum:

 On Thursday, 2 January 2014 at 20:49:32 UTC, Benjamin Thaut wrote:

 See http://wiki.dlang.org/DIP45
 I've been pushing for propper DLL support for a while. But it has not
 been important enough to be put on the roadmap yet. After the last
 thing I heard DLL support (and therefor shared library support) will
 be put on the roadmap of 2.066.

 Kind Regards
 Benjamin Thaut


 If you're also interested in runtime loading, it would be nice to have
 more feedback to this pull request:

    https://github.com/D-Programming-Language/druntime/pull/617


In my opinion such pull requests should wait until propper 
dll-export/dll-import semantics are implemented. Because they may infer 
a language change that makes bigger changes to the pull request neccessary.
But I will look into that pull request in detail on the weekend.

Kind Regards
Benjamin Thaut
Jan 02 2014
next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Thursday, 2 January 2014 at 21:07:43 UTC, Benjamin Thaut wrote:

 In my opinion such pull requests should wait until propper 
 dll-export/dll-import semantics are implemented. Because they 
 may infer a language change that makes bigger changes to the 
 pull request neccessary.


That's a good point.


 But I will look into that pull request in detail on the weekend.


Thanks!
Jan 02 2014
prev sibling parent Martin Nowak <code dawg.eu> writes:
On 01/02/2014 10:07 PM, Benjamin Thaut wrote:

 In my opinion such pull requests should wait until propper
 dll-export/dll-import semantics are implemented. Because they may infer
 a language change that makes bigger changes to the pull request neccessary.


What changes would affect the design?
Jan 02 2014