Bug 20529 – Cyclic dependency caused by import of core.time

Created attachment 1773 Small example extracted from Phobos with dustmite Executing run.sh in the attached example yields: object.Error@src/rt/minfo.d(371): Cyclic dependency between module std.traits and std.concurrency std.traits* -> std.range -> std.datetime -> std.datetime.timezone -> std.concurrency* -> std.traits* When you remove the import of core.time in std.datetime this dependency vanishes.

It's odd that std.datetime.timezone appears. That file doesn't seem to exist. Am I missing something?

Is it possible that phobos still gets linked somehow?

(In reply to RazvanN from comment #2) > Is it possible that phobos still gets linked somehow? Looks like. I haven't found anything in the sources, but I'm not very familiar with druntime. At least it looks really strange...

Try to rename the files to make sure that there isn't any name clash.

(In reply to RazvanN from comment #4) > Try to rename the files to make sure that there isn't any name clash. There is. It looks like std.datetime is taken from Phobos instead of the local version. But I get a different error, when I remove the local std.datetime, so it has to be included somewhere... When adding -defaultlib= to the calls of dmd I get a linker error about not finding std.datetime. Probably I made a mistake, when I reduced the output of dustmite any further. There I checked out dmd, druntime, tools and phobos, run make on dmd, druntime and tools and then used "make -f posix unittest" as a reduce command for dustmite. This should use local dmd, local runtime and local phobos, shouldn't it?

(In reply to berni44 from comment #5) > (In reply to RazvanN from comment #4) > > Try to rename the files to make sure that there isn't any name clash. > > There is. It looks like std.datetime is taken from Phobos instead of the > local version. But I get a different error, when I remove the local > std.datetime, so it has to be included somewhere... When adding -defaultlib= > to the calls of dmd I get a linker error about not finding std.datetime. > > Probably I made a mistake, when I reduced the output of dustmite any > further. There I checked out dmd, druntime, tools and phobos, run make on > dmd, druntime and tools and then used "make -f posix unittest" as a reduce > command for dustmite. This should use local dmd, local runtime and local > phobos, shouldn't it? I don't think so. It depends on how dustmite invokes dmd. It probably uses the default compiler, so if you have an out-of-the-box dmd installation it will probably use that one. I created a bash alias to my from-scratch installation binary and if I want any tool to use that one I update the makefile with the appropriate path to the binary. As far as dustmite is concerned, I haven't really used it so I cannot assist you there.

(In reply to RazvanN from comment #6) > I don't think so. It depends on how dustmite invokes dmd. dustmite doesn't invoke dmd at all, it calls the command you give them, in that case `make -f posix.mak unittest`. I removed now all rights to all dmds and phobos on my system and indeed this call depends somehow on some phobos installation. So I would have to rerun this reduction once again with all rights removed, but I fear I won't do that in the near future... I'm closing this, as I think it's not useful anymore.