Hi Iain, Thanks for the patch. I didn't see your reply until now (with the BTS you have to explicitly Cc the bug submitter, see [1]), and in the meantime I've managed to create a minimal variant of the parsec47 problem. There's a cycle of three modules, one of which does not use static constructors. I've included the code below.
If you compile this with gdc -o p47 P47Boot.d Ship.d P47GameManager.d Enemy.d you get a working program, and gdc -o p47 Ship.d Enemy.d P47Boot.d P47GameManager.d gives a broken program. I don't know if this is correct D code, but it bothers me that the compiler isn't consistent: either both versions should fail or both should work. (Consider that it's quite easy to write a build script that will link the objects in essentially random order, all you have to do is to use a wildcard to specify your source files.) Given the description in the manual, I'm guessing it should fail, which would mean that there's a bug in the cycle detection algorithm. Regards Peter De Wachter [1] http://www.debian.org/doc/developers-reference/pkgs.html#bug-answering ==> P47Boot.d <== module P47Boot; import P47GameManager; import std.stdio; public int main(char[][] args) { writefln("Hello world"); return 0; } ==> P47GameManager.d <== module P47GameManager; import Enemy; public class P47GameManager { } ==> Enemy.d <== module Enemy; import Ship; public class Enemy{ public static this() { } } ==> Ship.d <== module Ship; import P47GameManager; public class Ship { public static this() { } }
p47.tar.gz
Description: GNU Zip compressed data
