https://issues.dlang.org/show_bug.cgi?id=20529

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> ---
It's odd that std.datetime.timezone appears. That file doesn't seem to exist. Am I missing something?

--

https://issues.dlang.org/show_bug.cgi?id=20529

--- Comment #2 from RazvanN <razvan.nitu1305@gmail.com> ---
Is it possible that phobos still gets linked somehow?

--

https://issues.dlang.org/show_bug.cgi?id=20529

--- Comment #3 from berni44 <bugzilla@d-ecke.de> ---
(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...

--

https://issues.dlang.org/show_bug.cgi?id=20529

--- Comment #4 from RazvanN <razvan.nitu1305@gmail.com> ---
Try to rename the files to make sure that there isn't any name clash.

--

https://issues.dlang.org/show_bug.cgi?id=20529

--- Comment #5 from berni44 <bugzilla@d-ecke.de> ---
(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?

--

https://issues.dlang.org/show_bug.cgi?id=20529

--- Comment #6 from RazvanN <razvan.nitu1305@gmail.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=20529

berni44 <bugzilla@d-ecke.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #7 from berni44 <bugzilla@d-ecke.de> ---
(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.

--