|Posted by Kris|
in reply to Charles
Posted in reply to Charles
In article <firstname.lastname@example.org>, Charles says...
>The initalization depends on the order the files are compile as i recall , are the files in the right order for the build ?
>"Carlos Santander B." <email@example.com> wrote in message news:firstname.lastname@example.org...
>> Carlos Santander B. wrote:
>> > Walter, what does _minit() do? Because in dmain2.d, it's only in the Windows version, but not in the linux. Why?
>> > The problem I'm having is using Mango with a WinMain on Windows and a regular main on linux, because in the linux version it runs without problems, but on Windows, there is an access violation due to a different static initialization order. But when _minit() is commented out, it works again.
>> I must correct myself: commenting out doesn't work. The static ctor that is necessary still isn't called, so the problem is delayed for later. However it persists.
>> Carlos Santander Bernal
This is an old road that we've been down before (last August).
When a D executable starts, a dependency tree of static initializers is traversed recursively, to invoke the static constructors for each module (for module- and/or class-level). A similar thing is done for destructors at cleanup time.
This tree is built by the compiler, and is somewhat dependent upon the order of compiliation. However, the tree is expected (by the runtime) to be constructed in a manner such that constructors are invoked *in a valid order*. That is, the the dependency leaves are traversed first.
Back in August, there was a bug that caused all imports with a decorator (such
as private, public, package) to be excluded from the tree (!). That was resolved
in September, and static constructors have apparently been invoked correct since
that time (vis-a-vis Mango)
However, this is probably the first time that _minit() has been invoked explicitly (with Mango) and a similar problem has cropped up. It appears the tree is not being built correctly, not being traversed correctly, or a combination thereof.
I suspect the tree may not be fully constructed, but then I don't fully understand how the tree is combined across seperate link-units. Note that this shows up with Mango simply because it has a reasonably extensive suite of functionality, combined with a number of singletons that require correct instantiation. Interestingly, it has consistently been the Log4D subsystem that has exposed this issue.
There's more info over here, for those interested: http://dsource.org/forums/viewtopic.php?t=570
And some more, on the original issue, here: http://dsource.org/forums/viewtopic.php?t=334
Walter; can you help out with this, please?