Hello!
Currently, I'm doing a push towards getting shared library support in D into a much more usable state.
My approach has been this:
Build -betterC shared library, build full D executable that depends upon said shared library. Regardless of how you feel about -betterC, the reason it is in use here is to try and prevent issues surrounding druntime during my initial push.
I have not tested on Posix or used GDC. Right now I am only interested in Windows support as it has the most platform-specific issues and I am entirely ignoring Optlink (as far as I'm concerned that is WONTFIX).
Both ldc and dmd can work in this arrangement. However in both cases you need to manually generate ModuleInfo stubs. Like this:
export extern(C) void _D6dynlib3app12__ModuleInfoZ() {
asm {
naked;
di 0;
di 0x1000;
db 0;
}
}
Both LDC and DMD do not have a way to configure ModuleInfo generation. GDC does have a way to turn it on and off. LDC bug report [0].
If you remove -betterC
, that stub will no longer work in dmd due to duplicate symbols (that wasn't exported). LDC will compile okay.
In my codebase I have found that --fvisibility=public
is a very useful crutch given export is a linker directive that is pretending to be a visibility modifier (however let's ignore that since that is a DIP).
As part of my codebase I'm working towards getting dub working. I'm currently waiting on a PR that is blocked by a vibe.d regression with openssl[1]. This should mean build artifacts from dependencies will be copied to the target directory of a project and DLLs won't be linked against but instead will use their import libraries.
I've cherry-picked a few issues surrounding this [2], [3], [4].
However here are the things that if fixed, should lead to this working:
- In both LDC and DMD, implement switches to turn on and off ModuleInfo generation (ignoring -betterC switch).
- In DMD export ModuleInfo.
- In DMD implement a switch to turn on export for all symbols.
So to cap this off: right now DMD is basically not even an option for shared libraries unless you use -betterC or treat it as if it was a non-D library. LDC is possible for non -betterC
.
[0] https://github.com/ldc-developers/ldc/issues/3996
[1] https://github.com/dlang/dub/pull/2259
[2] https://issues.dlang.org/show_bug.cgi?id=22367
[3] https://issues.dlang.org/show_bug.cgi?id=9816
[4] https://issues.dlang.org/show_bug.cgi?id=4071