On Wednesday, 31 January 2018 at 15:58:02 UTC, 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:
>>> [...]
>>
>> 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
>
> Should I file a bug for dmd or the installer? Are 64-bit dub builds not done by CI on Windows? This is pretty embarassing.
>
> Atila

By any chance, is this on a corperate machine? I've hit the same issue seems to do with enforced windows group-policy which disables registry access for certain type of applications at my place.

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

On Wednesday, 31 January 2018 at 16:35:59 UTC, Arjan wrote:
> On Wednesday, 31 January 2018 at 15:58:02 UTC, Atila Neves wrote:
>> [...]
>
> By any chance, is this on a corperate machine? I've hit the same issue seems to do with enforced windows group-policy which disables registry access for certain type of applications at my place.

No, regular Windows 10 with VS 2015. Even if it were, dmd 2.077.1 works fine, 2.078.0 and 2.078.1 do not.

Atila

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

On 01/02/2018 17:16, Atila Neves wrote:
> 
>>
>>>
>>> Should I file a bug for dmd or the installer?
>>
>> It's a dmd issue.
> 
> https://issues.dlang.org/show_bug.cgi?id=18352

Thanks. https://github.com/dlang/dmd/pull/7827

On 23/01/2018 14:08, 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.

Should be fixed by https://github.com/dlang/dmd/pull/7828

Let's hope it makes it into 2.078.2 this time (I didn't expect another point-release).

On 02/01/2018 05:16 PM, Atila Neves wrote:
> 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.

That was my first suggestion as well, it's just to darn slow to call though. Executing vcvarsall.bat takes 2+ seconds just to setup the env variables, so we have to replicate what it does ourselves.

Maybe it's worth revisiting to figure out what takes so much time.

-Martin