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
