Permalink
Reply
Hello again!
--
As of some requests in DConf, I'll post here some things related (or not) to dub recipes.
Since there is so many ways to build D and dub is quite the main way, I'll try to show other uncommon ways to use it, this is more recommended to bigger projects since the standard one is enough for most.
I have been involved with some problems while dealing with shared libraries. Specifically on Windows and here I am writing how you can integrate shared libraries to your project, since it is a super powerful tool for plugin development:
For a dub.json configuration, let's first build your shared library:
"name": "shared_lib",
"targetType": "dynamicLibrary",
"dflags-ldc": [
"--link-defaultlib-shared"
]
The --link-defaultlib-shared here is the secret. It makes the D runtime be shared between the main D program and the shared library, with that, you'll get cool features such:
- A single GC (don't use more than 1)
- Able to share errors between those runtimes (you can do try/catch between them)
- More debug information
If you're using a shared library, you have a dependency and is on Windows, you'll need a special flag for avoiding a bug right now, this is some example:
"name": "shared_lib",
"targetType": "dynamicLibrary",
"dependencies": {"my_dependency": {"path": "libs/my_dependency"}},
"dflags-ldc": [
"--link-defaultlib-shared"
],
"lflags-windows-ldc": [
"/WHOLEARCHIVE:my_dependency"
]
You can see the new linker flag /WHOLEARACHIVE followed by the dependency (output name) my_dependency. This is required for every dependency because linkers are bad.
Basically your symbols get stripped out when including a library to your shared library and this fixes the problem. As of 2023, a solution to that is being researched, but don't let that stop you from using shared libraries.
