On Saturday, 23 January 2016 at 21:38:19 UTC, Igor wrote:
I feel like I am in the cave man times. I installed Dmd2 from
scratch. VisualD x64 project would not compile due to
libucrt.lib not being found.
Sorry you are having trouble. The Universal CRT and Visual Studio
2015 are very new and I'm sure there are still some bugs to work
out.
Using Process Monitor, it seems that dmd is looking all over
the place for libucrt.lib but can't find it. Check out sci.ini
has some weird results.
I have installed some windows kits and sdk's for win 8.1 and
win 10 but I do not remember all the details.
What I do know is that I have about 20 libucrt's in on my
harddrive(global search).
1. The archaic sc.ini file gets things backwards. It uses
VCINSTALLDIR before it is defined!
Well spotted but this case you are missing some details.
VCINSTALLDIR is used at that point so dmd linking will still work
for people who install using the zip file but run DMD through
Visual Studio Command Prompts (which define VCINSTALLDIR). You'll
notice LINKCMD is than replaced with a different value further
along by the installer. The comments could be better to explain
why it is this way.
It actually shouldn't matter if it's defined later though. My
understanding is the environment variables aren't expanded as the
config file is read. They all get read and set verbatim as
environment variables. Windows expands them once they are used
meaning VCINSTALLDIR would be set.
[snip]
Um, So, first off VCINSTALLDIR is used before defined!! Pretty
basic bug here, should never have happened. Second, UCRTVersion
is just wrong. I have no winv6.3 subdir. Windows 10 and VS2015
use some folder names like
C:\PF\Windows\Kits\10\Lib\10.0.10150.0
and
C:\PF\Windows\Kits\10\Lib\10.0.10240.0
We are using:
HKLM "Software\Microsoft\Windows Kits\Installed Roots"
"KitsRoot10"
Then searching for the latest UCRT version in a subdirectory.
That's probably where the bug is. This is brand new detection
however so it might be buggy.
You can see how it works here:
https://github.com/D-Programming-Language/installer/blob/master/windows/d2-installer.nsi#L379
Would you happen to know a better way to do this?
[snip]
The installer should be modernized and provide path information
and resolve dependencies properly before installing. It is
clear that dmd was not designed for windows use.
We make updates to it pretty much every release cycle. We'd love
some help making it bulletproof. Rock solid VS/Platform SDK
detection is what we want but it's proved a bit trickier than
expected (Microsoft has changed a few things up with different VS
releases so there is not just one way to do it).
