It makes me sick!

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, July 27, 2017 18:35:02 FoxyBrown via Digitalmars-d-learn wrote:
> On Thursday, 27 July 2017 at 18:14:52 UTC, Steven Schveighoffer
>
> wrote:
> > On 7/27/17 1:58 PM, FoxyBrown wrote:
> >> On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis
> >>
> >> wrote:
> >>> On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via
> >>>
> >>> Digitalmars-d-learn wrote:
> >>>> On 07/26/2017 09:20 PM, FoxyBrown wrote:
> >>>>  >> Somebody else had the same problem which they solved by
> >>>>
> >>>> removing
> >>>>
> >>>>  >> "entire dmd":
> >>>> http://forum.dlang.org/thread/ejybuwermnentslcyajs@forum.dlang.org
> >>>>
> >>>>  >> Ali
> >>>>  >
> >>>>  > Thanks, that was it. So I guess I have to delete the
> >>>>
> >>>> original dmd2 dir
> >>>>
> >>>>  > before I install each time... didn't use to have to do
> >>>>
> >>>> that.
> >>>>
> >>>> Normally, it shouldn't be necessary. The splitting of the
> >>>> datetime package[1] had this effect but I'm not sure why the
> >>>> installation process can't take care of it.
> >>>>
> >>>> Ali
> >>>>
> >>>> [1]
> >>>> http://dlang.org/changelog/2.075.0.html#split-std-datetime
> >>>
> >>> It _should_ take care of it. The fact that multiple people
> >>> have run into this problem and that the solution was to
> >>> remove dmd and then reinstall it implies that there's a bug
> >>> in the installer.
> >>>
> >>> - Jonathan M Davis
> >>
> >> I do not use the installer, I use the zip file. I assumed that
> >> everything would be overwritten and any old stuff would simply
> >> go unused.. but it seems it doesn't. If the other person used
> >> the installer then it is a problem with dmd itself not
> >> designed properly and using files that it shouldn't. I simply
> >> unzip the zip file in to the dmd2 dir and replace sc.ini...
> >> that has been my MO for since I've been trying out dmd2 and
> >> only recently has it had a problem.
> >
> > If you extracted the zip file over the original install, then
> > it didn't get rid of std/datetime.d (as extracting a zipfile
> > doesn't remove items that exist on the current filesystem but
> > aren't in the zipfile). So I can totally see this happening.
> >
> > I don't know of a good way to solve this except to tell people,
> > don't do that.
> >
> > -Steve
>
> But the issue was about missing symbols, not anything "extra". If
> datatime.d is there but nothing is using it, why should it
> matter? Why would it have any effect on the compilation process
> and create errors with D telling me something is being used that
> isn't?
>
> dmd shouldn't be picking up extraneous and non-connected files
> just for the fun of it.
>
> Basically, if no "references" escape out side of the D ecosystem,
> then there shouldn't be a problem.

You ended up with two versions of std.datetime. One was the module, and the
other was the package. importing std.datetime could have imported either of
them. dmd _should_ generate an error in that case, but I don't know if it
does or not. And depending on what you were doing, if you were dealing with
previously generated object files rather than fully building your project
from scratch, they would have depended on symbols that did not exist
anymore, because they were moved to other modules. And in that case, dmd
would not have generated an error about conflicting symbols, because the
code that was using the symbols had already been compiled. It would have
just complained about the missing symbols - which is what you saw.

If you'd just make sure that you uninstall the previous version before
installing the new one, you wouldn't have to worry about any such problems.
The installer would take care of that for you, but if you want to use the
zip file, then you're going to have to do it manually, and deleting the
directory and then unzipping instead of just unzipping on top of it would
take you less time than you've spent complaining about how it should have
worked.

- Jonathan M Davis