On Thursday, 27 July 2017 at 18:35:02 UTC, FoxyBrown wrote:
> But the issue was about missing symbols, not anything "extra". If datatime.d is there but nothing is using it, why should it matter?

YOU were using it with an `import std.datetime;` line. With the file still there, it sees it referenced from your code and loads the file... but since it is no longer used upstream, the .lib doesn't contain it and thus missing symbol.

On Thursday, 27 July 2017 at 18:47:57 UTC, Adam D. Ruppe wrote:
> YOU were using it with an `import std.datetime;` line

Of course, it is also possible that import was through a dependency of something you used, possibly including the standard library.

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

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

On 07/27/2017 11:47 AM, Adam D. Ruppe wrote:
> On Thursday, 27 July 2017 at 18:35:02 UTC, FoxyBrown wrote:
>> But the issue was about missing symbols, not anything "extra". If
>> datatime.d is there but nothing is using it, why should it matter?
>
> YOU were using it with an `import std.datetime;` line. With the file
> still there, it sees it referenced from your code and loads the file...
> but since it is no longer used upstream, the .lib doesn't contain it and
> thus missing symbol.
>

So, the actual problem is that given both

  datetime/package.d and
  datetime.d,

the import statement prefers the file. It could produce a compilation error.

If we don't want that extra check by the compiler, it would be better to keep datetime.d with a warning in it about the change. The warning could say "please remove this file". :)

Ali

On 07/27/2017 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote:

> You ended up with two versions of std.datetime. One was the module, and the
> other was the package.

I don't know how many people install from the zip file but I think the zip file should include a datetime.d file with the following statement in it:

static assert(false, "std.datetime is now a package; please remove this file");

Of course the problem is, the user would have to remove the file every time they unzipped potentially a later release. :/ We need more prominent information about the change I guess.

Ali

On 7/27/17 2:54 PM, Jonathan M Davis via Digitalmars-d-learn wrote:

> 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.

It does not (obviously, we are discussing it :)

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

-Steve

On 7/27/17 3:00 PM, Ali Çehreli wrote:
> On 07/27/2017 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
> 
>  > You ended up with two versions of std.datetime. One was the module, and the
>  > other was the package.
> 
> I don't know how many people install from the zip file but I think the zip file should include a datetime.d file with the following statement in it:
> 
> static assert(false, "std.datetime is now a package; please remove this file");

If std/datetime.d is there, how does one import std/datetime/package.d?

-Steve

On 07/27/2017 12:24 PM, Steven Schveighoffer wrote:
> On 7/27/17 3:00 PM, Ali Çehreli wrote:
>> On 07/27/2017 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
>>
>>  > You ended up with two versions of std.datetime. One was the module,
>> and the
>>  > other was the package.
>>
>> I don't know how many people install from the zip file but I think the
>> zip file should include a datetime.d file with the following statement
>> in it:
>>
>> static assert(false, "std.datetime is now a package; please remove
>> this file");
>
> If std/datetime.d is there, how does one import std/datetime/package.d?
>
> -Steve

Currently not possible. (Thank you for the bug report. :) ) I tried to find a band aid to the issue. Otherwise, I agree that the compiler should issue an error.

Ali

On Thursday, 27 July 2017 at 03:34:19 UTC, FoxyBrown wrote:
> Knowing that every time I upgrade to the latest "official" D compiler I run in to trouble:
>
> I recompiled gtkD with the new compiler, same result.  My code was working before the upgrade just fine and I did not change anything.

I've had to delete my previous install at least 2 times before. It is an infrequent headache I hit because I'm not following appropriate install steps. I cannot expect upstream to support a DMD folder which has additional files from what they have provided.

Here is my attempt to explain the problem.

* std/datetime.d has a different mangled name than std/datetime/package.d.
* The phobos.lib contains the std.datetime.package module and no longer contains the std.datetime module.
* When the compiler is reading your code it sees imports for std.datetime and looks at the import location /install/directory/dmd2/src/std and it writes a reference to the std/datetime.d file.
* The linker takes over, loads up phobos.lib and barfs since the referenced symbol was not compiled into your obj file nor the released phobos.lib.

More recently the headache I've been hitting with upgrades is improvements to @safe and such. The bug fixes around this cause libraries I'm using to fail compilation. Even this isn't so bad, but the library that files is a dependent of a dub package I'm using. This means I have to wait for the dependent package to update and release followed by the dub package I'm actually referencing. So even if I create the needed patches, I have to wait at each step for the author to merge and tag their release. (or create a branch of the project and throw it in dub so I can control all the updates)