www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Crazy compile time errors with DMD 2.075.1 & 2.076.0

reply Joel <joelcnz gmail.com> writes:
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)
/usr/local/opt/dmd/include/dlang/dmd/std/datetime/systime.d(7660,58): Error:
std.datetime.date.splitUnitsFromHNSecs!"hours".splitUnitsFromHNSecs at
/usr/local/opt/dmd/include/dlang/dmd/std/datetime/date.d(9997,6) conflicts with
core.time.splitUnitsFromHNSecs!"hours".splitUnitsFromHNSecs at
/usr/local/opt/dmd/include/dlang/dmd/core/time.d(4250,6)
/usr/local/opt/dmd/include/dlang/dmd/std/datetime/systime.d(7661,62): Error:
std.datetime.date.splitUnitsFromHNSecs!"minutes".splitUnitsFromHNSecs at
/usr/local/opt/dmd/include/dlang/dmd/std/datetime/date.d(9997,6) conflicts with
core.time.splitUnitsFromHNSecs!"minutes".splitUnitsFromHNSecs at
/usr/local/opt/dmd/include/dlang/dmd/core/time.d(4250,6)
../JMiscLib/source/jmisc/base.d(33,19): Error: template instance 
std.datetime.systime.SysTime.opCast!(DateTime) error instantiating
../JMiscLib/source/jmisc/base.d(23,4): Error: template instance 
jmisc.base.upDateStatus!string error instantiating
../JecLib/source/jec/input.d(357,26): Error: void has no value
../JecLib/source/jec/input.d(357,26): Error: incompatible types 
for ((dateTimeString()) ~ (" ")): 'void' and 'string'
../JecLib/source/jec/input.d(274,17): Error: template instance 
jec.input.InputJex.addToHistory!dstring error instantiating
source/app.d(31,7): Error: no property 'setupBoardPieces' for 
type 'int'
dmd failed with exit code 1.

[1] 
https://www.dropbox.com/s/eofa70od1hlk6ok/ArchiveOddCompileErrors.zip?dl=0
Sep 03 2017
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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.

Ali
Sep 03 2017
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
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
Sep 03 2017
parent Joel <joelcnz gmail.com> writes:
On Monday, 4 September 2017 at 04:45:27 UTC, Jonathan M Davis 
wrote:

 On Sunday, September 03, 2017 21:22:14 Ali Çehreli via 
 Digitalmars-d-learn wrote:

 [...]


 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.

 [...]


Found the problem, this [1] in my dub.json file. Removed it, and 
it now works as expected.

Thanks for the replies.

[1] "dflags-dmd": [
                "-transition=import"],
Sep 03 2017