View mode: basic / threaded / horizontal-split · Log in · Help
November 07, 2012
Current status of DLLs
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.
November 07, 2012
Re: Current status of DLLs
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
November 07, 2012
Re: Current status of DLLs
can you statically link D to C++(no dll)?
November 07, 2012
Re: Current status of DLLs
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
November 07, 2012
Re: Current status of DLLs
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..
November 07, 2012
Re: Current status of DLLs
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
November 08, 2012
Re: Current status of DLLs
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.
November 08, 2012
Re: Current status of DLLs
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
Top | Discussion index | About this forum | D home