Release D 2.078.1

[Atila Neves]

On Wednesday, 31 January 2018 at 19:09:03 UTC, Rainer Schuetze 
wrote:
>
>
> On 31/01/2018 16:58, Atila Neves wrote:
>> On Thursday, 25 January 2018 at 20:11:54 UTC, Rainer Schuetze 
>> wrote:
>>>
>>>
>>> On 25.01.2018 14:54, Atila Neves wrote:
>>>> On Tuesday, 23 January 2018 at 15:16:02 UTC, Andre Pany 
>>>> wrote:
>>>>> On Tuesday, 23 January 2018 at 13:08:35 UTC, thedeemon 
>>>>> wrote:
>>>>>> On Monday, 22 January 2018 at 20:43:56 UTC, Martin Nowak 
>>>>>> wrote:
>>>>>>> Glad to announce D 2.078.1.
>>>>>>
>>>>>>
>>>>>> The Windows 7z archive version now has much simpler 
>>>>>> sc.ini, in fact too simple.
>>>>>> With Visual C++ 2015 x64 Native Build Tools now trying to 
>>>>>> run
>>>>>> dmd -m64 hi.d
>>>>>> I get
>>>>>> LINK : fatal error LNK1104: cannot open file 'libucrt.lib'
>>>>>> Error: linker exited with status 1104
>>>>>>
>>>>>> So I needed to edit sc.ini and add back
>>>>>> LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"
>>>>>> to the [Environment64] section.
>>>>>>
>>>>>> Then it went just as 2.078.0 - still missing 
>>>>>> legacy_stdio_definitions.lib that I need to add manually 
>>>>>> in the command line.
>>>>>
>>>>> Did you call vcvarsall in the current dos box/PowerShell? 
>>>>> It is a tool included with all visual studio variants.
>>>>>
>>>>> Kind regards
>>>>> Andre
>>>>
>>>> I just ran into this today. With the dmd 2.077.1 Windows 
>>>> installer things just work, and it's never necessary to call 
>>>> vcvarsall.bat to build D code for 64-bit.
>>>>
>>>> Since dmd 2.078.0, with Visual Studio 2015, nothing works 
>>>> anymore, and sc.ini doesn't seem to reference Visual Studio 
>>>> at all like it used to.
>>>>
>>>> Atila
>>>
>>> Visual Studio is supposed to be detected by dmd now, either 
>>> from the environment or from the registry.
>>>
>>> What errors do you get? Try running with -v to show the 
>>> linker command line.
>> 
>> $ dub init
>> $ dub build --arch=x86_64
>> Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe 
>> for x86_64.
>> example ~master: building configuration "application"...
>> Linking...
>> LINK : fatal error LNK1104: cannot open file 'shell32.lib'
>> 
>> -v shows that it's linking like so:
>> 
>> C:\D\dmd2\windows\bin\dmd.exe 
>> -of.dub\build\application-debug-windows-x86_64-dmd_2078-70A25404824ECE07D24A9F4D03E746CD\example.exe .dub\build\application-debug-windows-x86_64-dmd_2078-70A25404824ECE07D24A9F4D03E746CD\example.obj -m64 -g
>
> Unfortunately, that is not dmds output of the linker command 
> line, but dubs invocation of dmd. Just try "dmd -v -m64 test.d".

Sorry, I misunderstood what you meant. It's:

C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\bin\link.exe /NOLOGO app   /OPT:NOICF  
/LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\lib\amd64" /LIBPATH:"C:\Program Files (x86)\Windows 
Kits\10\Lib\10.0.10240.0\ucrt\x64" legacy_stdio_definitions.lib


There are 3 shell32.lib files on my system, located at:

C:\Program Files (x86)\Windows 
Kits\8.1\Lib\winv6.3\um\{arm,x64,x86}

Notice that it's similar to the path being used above. Given that 
cl.exe doesn't have a problem running on my system I went and 
looked at vcvarsall.bat expecting there to be checks for either 
8.1 or 10. I was right, there's logic to figure it out.

It'd probably be easier to `executeShell("vcvarsall.bat")` than 
trying to replicate the logic in dmd itself. It's bound to get it 
wrong (as it has) and we don't have Microsoft's resources to test 
backwards compatibility.

>
> Does Arjan's suggestion help, i.e. are you working as a 
> restricted user? Did you install VS for the current user only 
> (not sure if that's actually possible)?

I've installed dmd 2.077.1 and dmd 2.078.1 now several times, 
each time erasing the other. It's a regression.

>
>> 
>> Should I file a bug for dmd or the installer?
>
> It's a dmd issue.

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