Release D 2.078.1

[Rainer Schuetze]

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

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)?

> 
> Should I file a bug for dmd or the installer? 

It's a dmd issue.

> Are 64-bit dub builds not 
> done by CI on Windows? This is pretty embarassing.

Every PR is tested against both VS2013 (auto-tester) and VS2015 (Appveyor).