On Wednesday, 15 December 2021 at 12:02:08 UTC, Jan wrote:
On Wednesday, 15 December 2021 at 11:03:27 UTC, rikki
cattermole wrote:
On 15/12/2021 11:54 PM, Jan wrote:
On Wednesday, 15 December 2021 at 09:36:54 UTC, Jan wrote:
Unfortunately it's the "annoying little details" that I
immediately bumped into.
Just another example: I just learned that linking against C++
DLLs is quite limited. I ran into the issue that linking in
an external variable doesn't work (even though the mangled
name that D chooses is correct), because DLLs work
differently than static linking does
Are you sure that on the shared library side it was marked as
exported?
If a symbol is not exported, there is no guarantee (nor reason
to think) that it will be visible during runtime linking to
said shared library/executable.
This isn't unique to D, its just how linkers work.
Yep, checked that. Even checked the .exp file and compared the
mangled name there with the mangled name that D tries to use,
they are the same.
You probably know this but just in case - unlike C++ in D
variables by default have thread local storage, to link with C++
global variable you need to use __gshared storage modifier in D,
it is similar to 'shared' variable that unlike 'shared' tells the
compiler "I know how to synchronize it myself".
```d
module a;
struct Foo {}
extern(C++)
__gshared Foo globalFoo;
```
