Bug 14546 – "ClockType.uptime is not supported by MonoTimeImpl on this system"
Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
x86_64
OS
Linux
Creation time
2015-05-05T06:47:00Z
Last change time
2017-07-19T17:41:33Z
Assigned to
nobody
Creator
dlang-bugzilla
Comments
Comment #0 by dlang-bugzilla — 2015-05-05T06:47:04Z
Attempting to build dlang.org on a Linux/64 system results in the following error message:
../dmd/src/dmd -conf= -c -w -o- -Isrc -Iimport -version=CoreDdoc -Df/home/dlang/d/dlang.org/web/phobos-prerelease/core_time.html project.ddoc /home/dlang/d/dlang.org/macros.ddoc /home/dlang/d/dlang.org/html.ddoc /home/dlang/d/dlang.org/dlang.org.ddoc /home/dlang/d/dlang.org/.generated/2.067.1.ddoc /home/dlang/d/dlang.org/std.ddoc /home/dlang/d/dlang.org/std_navbar-prerelease.ddoc /home/dlang/d/dlang.org/.generated/modlist-prerelease.ddoc src/core/time.d
src/core/time.d(2696): Error: static assert "ClockType.uptime is not supported by MonoTimeImpl on this system."
Comment #1 by issues.dlang — 2015-05-07T02:41:47Z
It must be an issue related to version(CoreDdoc), since ClockType.uptime doesn't even exist on Linux. I guess that MonoTimeImpl needs to be version(CoreDdoc)-ed as well.
Comment #2 by dlang-bugzilla — 2015-05-08T08:23:50Z
Jonathan, could you please look into this? As I said it's preventing us from building dlang.org, which means it's blocking any and all website updates.
Comment #3 by issues.dlang — 2015-05-08T11:46:09Z
I'll try and put something together this evening. Martin created a pull request that attempted to fix it
https://github.com/D-Programming-Language/druntime/pull/1257
but it's running afoul of the same compiler bug that previous version of the ClockType/MonoTimeImpl PR did. If we could put the static constructor inside of MonoTimeImpl itself (as that PR did originally), then we wouldn't be hitting this problem with the docs, but a dmd bug prevents it. :(
I think that I can fix it by simply using version(CoreDdoc) in key places, but I don't know how much I'll be forced to version to make the docs build - hopefully not a lot.
Regardless, this situation makes me wonder if we should add the documentation build to the autotester to catch this sort of thing in the future.