www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Current status of DLLs

reply "Matt" <webwraith fastmail.fm> writes:
The DLL page on the main D site is out of date in its example, 
importing module std.gc, which doesn't exist. Has connecting to 
DLLs become easier, harder, or just plain different? And in what 
ways should I go about doing so? My personal requirement is 
dynamic loading, so any help would be much appreciated.
Nov 06 2012
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 07.11.2012 03:04, schrieb Matt:

 The DLL page on the main D site is out of date in its example, importing
 module std.gc, which doesn't exist. Has connecting to DLLs become
 easier, harder, or just plain different? And in what ways should I go
 about doing so? My personal requirement is dynamic loading, so any help
 would be much appreciated.


AFAIK dlls are possible without problems if you only have a C-Style 
interface. As soon as you want to have a D-Interface to a dll things get 
really ugly / near impossible.

For example: Exporting the Module init symbol is not supported, so every 
module that only exists in a dll will generate a linker error. Also I 
had some cases where even the vtable symbol did not get exported 
(despite the that the class was declared as export) and caused yet 
another linker error. Also there are quite some issues with thread local 
storage and data symbols are not supported at all by dmd. The only thing 
that truly works is exporting C-Style functions or COM.

Also its not possible to build druntime as a shared dll, nor phobos, so 
you would have to duplicate all the functionality in there for every dll 
you have.

I decided to link everything statically until the situation dramatically 
improves.

Kind Regards
Benjamin Thaut
Nov 07 2012
next sibling parent reply "DypthroposTheImposter" <mcbracket gmail.com> writes:
  can you statically link D to C++(no dll)?
Nov 07 2012
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 07.11.2012 20:01, schrieb DypthroposTheImposter:

   can you statically link D to C++(no dll)?


If you compile it with a compiler that puts out the same object format, yes.

But if you want to have a interface to C or C++ you will need a C-Style 
interface anyway, so that works with DLLs.

Kind Regards
Benjamin Thaut
Nov 07 2012
parent reply "DypthroposTheImposter" <mcbracket gmail.com> writes:
  thanks, do you happen to know which D compilers can output to a 
format that is capable of linking with visual studio(specifically 
2012) C++?  Ya I'm ok with the C interface, kinda what I 
expected..
Nov 07 2012
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 07.11.2012 21:31, schrieb DypthroposTheImposter:

   thanks, do you happen to know which D compilers can output to a format
 that is capable of linking with visual studio(specifically 2012) C++?
 Ya I'm ok with the C interface, kinda what I expected..


The best option would be to use the digital mars c++ compiler to compile 
your c++ part and link that against your D code compiled with dmd. The 
same could be done with the gcc toolset, so compile your c++ code with 
g++ and your D code with gdc and then link it.

The current developement version of dmd is able to put out a visual 
studio compatible object file but only in 64-bit mode. And its experimental.

For interface to c++ you might want to read the documentation. It does 
not have to be entierly C-Style.
http://dlang.org/cpp_interface.html

Kind Regards
Benjamin Thaut
Nov 07 2012
prev sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 7 November 2012 at 10:24:25 UTC, Benjamin Thaut 
wrote:

 For example: Exporting the Module init symbol is not supported, 
 so every module that only exists in a dll will generate a 
 linker error. Also I had some cases where even the vtable 
 symbol did not get exported (despite the that the class was 
 declared as export) and caused yet another linker error. Also 
 there are quite some issues with thread local storage and data 
 symbols are not supported at all by dmd. The only thing that 
 truly works is exporting C-Style functions or COM.


Actually, when making DLLs with GDC, the module init is 
automatically exported.
Nov 07 2012
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 08.11.2012 08:43, schrieb Jakob Ovrum:

 On Wednesday, 7 November 2012 at 10:24:25 UTC, Benjamin Thaut wrote:

 For example: Exporting the Module init symbol is not supported, so
 every module that only exists in a dll will generate a linker error.
 Also I had some cases where even the vtable symbol did not get
 exported (despite the that the class was declared as export) and
 caused yet another linker error. Also there are quite some issues with
 thread local storage and data symbols are not supported at all by dmd.
 The only thing that truly works is exporting C-Style functions or COM.


 Actually, when making DLLs with GDC, the module init is automatically
 exported.



Yes, but I talk the reference implementation (DMD) here.

GDC has various other problems:
  - The latest binary release is 2.058
  - Phobos and druntime are not trivially recompileable without 
compiling the whole thing beforehand
  - Couldn't find clear compiliation setup documents.
  - Phobos and druntime have a completely different folder structure 
(for whatever reason)

Also the thread local storage issue is a druntime issue AFAIK and exists 
within gdc as well.

Kind Regards
Benjamin Thaut
Nov 08 2012