Crazy compile time errors with DMD 2.075.1 & 2.076.0

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, September 03, 2017 21:22:14 Ali Çehreli via Digitalmars-d-learn 
wrote:
> On 09/03/2017 09:03 PM, Joel wrote:
>  > One of my small programs doesn't compile any more since, said, DMD
>  > versions.
>  >
>  > I've got other programs that do work, but I can't see what's different
>  > about them?!
>  >
>  > I'm using macOS.
>  >
>  > [1] Here is the program and stuff. It uses DSFML 2.1.1, but I haven't
>  > added the dynamic files for it.
>  >
>  > giver ~master: building configuration "application"...
>  > /usr/local/opt/dmd/include/dlang/dmd/std/datetime/systime.d(7652,52):
>  > Error:
>  > std.datetime.date.splitUnitsFromHNSecs!"days".splitUnitsFromHNSecs at
>  > /usr/local/opt/dmd/include/dlang/dmd/std/datetime/date.d(9997,6)
>  > conflicts with
>  > core.time.splitUnitsFromHNSecs!"days".splitUnitsFromHNSecs at
>  > /usr/local/opt/dmd/include/dlang/dmd/core/time.d(4250,6)
>
> Are you installing from the zip distribution? If so, unfortunately,
> changes made to std.datetime are not compatible for that way of
> installing. (The large datetime file has been split into modules, making
> datetime a package.)
>
> First delete the old dmd directories and unzip again.

Much as some people have been doing it for some reason, I really don't
understand why anyone would be unzipping the .zip file on top of a previous
release and expect it to work. If enough stuff stays in the same place, then
it can work, but as soon as any files are moved or removed, odds are that
you're screwed.

But given the paths to the Phobos source files that are listed there, it
looks like they were either installed with something other than .zip file,
or they were manually installed from the .zip file. So, I'm not sure that
that's the problem here. And the error messages are pretty weird, because
they're complaining about a private function from core.time and a package
one from std.datetime.date conflicting. It isn't mentioning std.datetime as
a module anywhere, and it's not talking about linker problems, which is more
what I'd expect when you end up with both the old module and the new package
together or if you're accidentally using a library that wasn't rebuilt for
the new release. So, I have no idea what's happening here.

It's quite possible that the system in question is not dealing a clean 2.076
environment, and it's possible that not everything was built from scratch
for the new release like it should have been, but the error messages don't
seem to be complaining about that. To figure it out, we'd probably need a
reproducible example.

- Jonathan M Davis