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.

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

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

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

 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..

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

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.

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