[kris]

Here's another bit of code to try, which emits the modules in the order they are constructed (adapted from Walter's runtime code):

[Carlos]

[Carlos]

[kris]

[kris]

[teqdruid]

Sure. If I try to run it without adding some hack code to Manager.d, it segfaults before getting to main. Here's the stacktrace:

[kris]

[teqdruid]

Yeah... DMD 0.113 on Linux.

[kris]

This is disheartening;

Sooner or later, most D programmers will find the need for a static ctor. In the Mango libraries, they are used to initialize all manner of Singletons; e.g. Stdout & Stdin, various lookup tables (Uri, ServletContext, etc), even instances of exceptions. This is done so the rest of the code can make certain valid assumptions about the environment, which leads to a faster, more manageable, and more maintainable code-base overall.

Static ctors will often form a dependency graph. Therefore, the order in which static ctors are invoked must respect any and all interdependencies. Without this behavior, the utility of static ctors is seriously crippled. Looking at the compiler source-code, there is precious little evidence that it does anything particularly useful with regard to this ordering. Hence, whilst the runtime code (moduleinit.d) tries valiantly to visit the constructors in a valid order, the data-structures it traverses are laid out in a fashion dictated by the order of compilation. This is farcical. As it turns out, Walter has recently added a delicate little footnote to the relevant documentation (�the order in which they are called is not defined�).

[kris]

I've uploaded a mango.servlet.ServletContext which avoids the call to Logger from within the static ctor. This should alleviate the problem in a number of cases, but the underlying issue remains.

You should be OK to download just that one file.

[kris]

Now that I understand what the true issue is, I've uploaded a mango.log.Logger change which persuades the compiler to do the right thing.

edit: hadn't seen this problem since last September, simply because I had my imports ordered in the 'right' fashion. It should be OK from this point on, and Walter will likely patch the compiler to avoid this kind of thing in the future. Sorry for the inconvenience ...

[kris]

To wrap this up, here's a somewhat deeper look at the problem:

Each object file appears to contain a list of ModuleInfo descriptors, representing those imports which have static ctors ~ where the list order follows that of the module source-code. By maintaining such a list within each module object-file, the design apparently expects to resolve static ctor dependencies at startup time by recursively traversing the ModuleInfo structures across all files linked. I'm guessing there's a little mojo to link the lists together.

The problem occurs when one module acts as a 'proxy' for another in this regard. Specifically:

- module C has a static ctor
- module B imports, and references C, but has no static ctor of its own
- module A imports B, and has a static ctor *indirectly* dependent upon C

In this case, A does not need to import C (doesn't even know it exists), though it must import B. However, the compiler mistakenly drops C from the list belonging to A because the import of B does not expose any static ctors therin. C is orphaned via the lack of a static ctor in B.

Thus, the chain of dependencies is broken. I checked this by adding a dummy static ctor (module-level) to B and, sure enough, the graph was restored.

This whole thing might be resolved by ensuring the compiler does not drop C, just because B does not have a static ctor. The blunt way to do this would be to implicitly inject a static ctor into those modules that don't have one themselves, yet import modules that do (this is already done for class-level static ctors).

[Carlos]

With DMD 0.114 the problem remains, but now with module Token, in both Windows and linux. You can test it with the lineio sample.

[kris]

[Carlos]