Cycle detected between modules with ctors/dtors

[rumbu via Digitalmars-d-learn]

On Tuesday, 3 March 2015 at 18:55:49 UTC, Steven Schveighoffer 
wrote:

>>
>> Only one of the listed modules has a static contructor
>> (system.globalization) and that constructor doesn't use any 
>> information
>> from other modules.
>
> It's a complex problem. Because we don't control the linker, we 
> cannot establish an order of execution for the module system. 
> It must be a directed acyclic graph. Although, cycles are 
> allowed that only involve a single module with ctor/dtors, or 
> with no ctor/dtors. But we have to detect it at runtime during 
> startup.
>
> two of those modules should have static ctor or dtor (they may 
> have either to cause the error).
>
>> The message is not too helpful, I have no clue where to start 
>> searching
>> for the error source, the source code has more than 25k LOC. 
>> In fact, I
>> don't believe this error is true, since I have only two 
>> non-linked
>> modules with static contructors.
>
> Just look for "static this" and "static ~this" inside those 
> files identified.
>
>
> -Steve

One of the listed modules had a ctor. Another one - curiously - 
not listed in the cyclic error - had a static dtor, and this 
module was imported by two of them.

Anyway, reduced case scenario:

module a;
import b;
static this();
-----
module b;
import a;
static ~this();

As I supposed, this is a false error, the order of execution 
seems very clear to me, but not for the runtime. Even if I have 
two ctors, I think it's better to relax this rule, maybe the 
constructors are not dependent one of each other to have cyclic 
errors. In my case, one of the constructors loads some resources 
bound to the executable and the destructor is simply a winapi 
call to CoUninitialize, totally unrelated.