On Thursday, 25 February 2016 at 16:05:37 UTC, Benjamin Thaut
wrote:
On Thursday, 25 February 2016 at 14:42:14 UTC, Thalamus wrote:
your entry point.
Hi Guillaume,
Thanks for responding so quickly! I had found that wiki page
before and I'd been following the "DLLs with a C Interface"
section closely. I had forgotten to add -shared when building
the DLL, but the behavior didn't change when I added it. So, I
added a call to Runtime.initialize() as the first line of the
endpoint I'm exposing. (I also made sure that this was the
only endpoint invoked and that it was only invoked once just
to be cautious.) I can see Runtime.initialize() being called,
but the Class A shared static constructor still is not called
when run from the C# EXE.
Do you have any other ideas?
In the meantime, I'm working on putting together a minimal
repro source, but the scenario is a bit complicated so there's
a lot of details to whittle away.
thanks!
Gene
You shouldn't be calling Runtime.initialize() manually. Just do
the following in one of your source files:
import core.sys.windows.dll;
mixin SimpleDllMain;
This will generate a DllMain that will correctly initialize and
deinitialize druntime.
Kind Regards
Benjamin Thaut
Thanks Benjamin. When I went to whittle this down to its barest
essentials, though, the repro is pretty simple. It involves LIBs,
but not Dlls, and it doesn't require anything but a single D EXE.
NOTE: if attempting to repro any of this, you must do a clean
build after changing build.cmd or main.d before you'll see a
change in behavior. I have the shared static ctors output files
to make it really easy to see.
If you have Class A:
module ClassA;
import std.file;
import std.stdio;
export class ClassA
{
shared static this()
{
File file = File(r"c:\A.txt", "w");
file.writeln("Called A's shared static constructor.");
file.flush();
file.close();
}
}
and you have Class B:
module ClassB;
import std.file;
import std.stdio;
export class ClassB
{
shared static this()
{
File file = File(r"c:\B.txt", "w");
file.writeln("Called B's shared static constructor.");
file.flush();
file.close();
}
}
and you have main.d:
void main()
{
}
And you build it in one step into an EXE:
dmd -m64 -debug ClassA.d ClassB.d main.d -ofDriver.exe
Then you run Driver.exe, both A.txt and B.txt are created.
But, if you build it as a LIB and then link the LIB to the EXE:
dmd -c -lib -m64 -debug ClassA.d ClassB.d -ofInit.lib
dmd -m64 -debug Init.lib main.d -ofDriver.exe
When you run Driver.exe, neither are created. If you then add
"import ClassA" to main.d and clean build, only A.txt will be
created, or instead if you add "import ClassB", then only B.txt
is created. Also, if either of these is included, Driver.exp and
Driver.lib are emitted by the build, whereas otherwise they
aren't.
It looks from this like a class in a linked LIB that is not
directly imported will not have its shared static constructor
called. Am I missing something obvious? :)
Long term I will need all this not only in separate LIBs but in
separate DLLs. My scenario is roughly like this (-> indicate
dependencies):
ClassA : IClass -> ClassManagement
ClassB : IClass -> ClassManagement
EntryPoint -> ClassManagement, ClassB, IClass
Then EntryPoint asks ClassManagement to give it an instance of
ClassB's complement (ClassA). ClassManagement only knows anything
about any of these classes via TypeInfo_Class object mappings,
and it uses Object.factory to instantiate them. EntryPoint and
its dependencies then work with that object via the IClass
interface. I've gotten this to work in C# easily and C++ with
some effort. (Class map population was, of course, very different
for each, though.)
I can probably figure out a way to make this work for now, but if
there's a way to ensure shared static ctors are run in this
scenario without importing modules across separation boundaries,
it would be a very good thing.
thanks!
Gene
