Community

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

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

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