https://issues.dlang.org/show_bug.cgi?id=14863
--- Comment #1 from Jonathan M Davis <[email protected]> --- Great... People are still using kernels that old? This sort of problem didn't even occur to me. We really aren't set up to have different C headers depending on the kernel version and the like, and we're certainly not set up to support different ClockTypes depending on your kernel version - though in theory, it's supposed to be set up so that if you don't explicitly use a particular ClockType, it wouldn't matter. The GC and runtime should only care about MonoTime itself - i.e. MonoTimeImpl!(ClockType.normal) and not any of the other instantiations of MonoTimeImpl. I guess that in one of the rounds of changes that we made relating to static constructor bugs must have resulted in the clock frequency being grabbed for all of the ClockTypes that the system supports (or at least supposedly supports). *sigh* The simplest solution of course would be to simply get rid of ClockType.bootTime, though that definitely would suck, and I don't know how we'd decide when to readd it (I really don't want to have start worrying about kernel versions). Other than that, presumably, we have to make sure that none of the ClockTypes other than ClockType.normal get used in any way unless someone uses them in their own program. I guess that I'll have to find time to dig into this ASAP. --
