It makes me sick!

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/27/17 2:35 PM, FoxyBrown 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.
> 
> 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.

They aren't non-connected. If you import std.datetime, the compiler is 
first going to look for std/datetime.d. Not finding that, it will look 
for std/datetime/package.d.

The latter is what is supported and built into the library for 2.075. 
The former is a ghost of the original installation, but it's what *your* 
code is importing. You might not even import std.datetime, but rather 
something else that imports it. Either way, the compiler generates the 
wrong mangled names, and they don't match up with the ones in the library.

-Steve