www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dmd sc.ini and VS do not work well together!

reply Igor <Vladamir.I google.com> writes:
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.

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!


This is the exact file generated on my system minus the comments:

[Version]
version=7.51 Build 020
; environment for both 32/64 bit
[Environment]
DFLAGS="-I% P%\..\..\src\phobos" 
"-I% P%\..\..\src\druntime\import"
LIB="% P%\..\lib"

[Environment32]
LIB="% P%\..\lib"
LINKCMD=% P%\link.exe

[Environment64]
LIB="% P%\..\lib64"
DFLAGS=%DFLAGS% -L/OPT:NOICF
LINKCMD=%VCINSTALLDIR%\bin\link.exe ;;; <<<<<<<<<<< UM, Where is 
VCINSTALLDIR?

VCINSTALLDIR=C:\PF\VS2015\VC\
WindowsSdkDir=C:\PF\Windows Kits\8.1\
UniversalCRTSdkDir=C:\PF\Windows\Kits\10\
UCRTVersion=winv6.3
LINKCMD=%VCINSTALLDIR%\bin\x86_amd64\link.exe
PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\bin
LIB=%LIB%;"%VCINSTALLDIR%\lib\amd64"
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\um\x64"
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"
LIB=%LIB%;"%WindowsSdkDir%\Lib\winv6.3\um\x64"
LIB=%LIB%;"%WindowsSdkDir%\Lib\win8\um\x64"
LIB=%LIB%;"%WindowsSdkDir%\Lib\x64"
LIB=%LIB%;"%DXSDK_DIR%\Lib\x64"

[Environment32mscoff]
LIB="% P%\..\lib32mscoff"
DFLAGS=%DFLAGS% -L/OPT:NOICF
VCINSTALLDIR=C:\PF\VS2015\VC\
WindowsSdkDir=C:\PF\Windows Kits\8.1\
UniversalCRTSdkDir=C:\PF\Windows\Kits\10\
UCRTVersion=winv6.3
LINKCMD=%VCINSTALLDIR%\bin\link.exe
PATH=%PATH%;%VCINSTALLDIR%\bin
LIB=%LIB%;"%VCINSTALLDIR%\lib"
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\um\x86"
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x86"
LIB=%LIB%;"%WindowsSdkDir%\Lib\winv6.3\um\x86"
LIB=%LIB%;"%WindowsSdkDir%\Lib\win8\um\x86"
LIB=%LIB%;"%WindowsSdkDir%\Lib"
LIB=%LIB%;"%DXSDK_DIR%\Lib\x86"



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


Which contains the libucrt libs. It seems the installer is pretty 
ignorant of reality and almost surely not designed by someone 
that uses windows as a development platform. As of now I 
personally cannot use dmd to build windows apps. I imagine there 
are other people in similar situations with similar build setups.

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.
Jan 23
next sibling parent Igor <Vladamir.I google.com> writes:
 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.
Also, sc.ini global variables should be at the top most section:
 [Environment]
 DFLAGS="-I% P%\..\..\src\phobos" 
 "-I% P%\..\..\src\druntime\import"
 LIB="% P%\..\lib"
These should be placed here instead of the individual sections as it creates redunancy and is bug prone: VCINSTALLDIR=C:\PF\VS2015\VC\ WindowsSdkDir=C:\PF\Windows Kits\8.1\ UniversalCRTSdkDir=C:\PF\Windows\Kits\10\ or even in [Version]
Jan 23
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/23/2016 1:38 PM, Igor wrote:
 As of now I personally cannot use dmd to build windows apps.
You know, sc.ini is editable by you!
Jan 23
parent reply Igor <Vladamir.I google.com> writes:
On Saturday, 23 January 2016 at 22:47:35 UTC, Walter Bright wrote:
 On 1/23/2016 1:38 PM, Igor wrote:
 As of now I personally cannot use dmd to build windows apps.
You know, sc.ini is editable by you!
Yes, But why do you expect me to be so smart or have a desire to waste my time looking for paths and such when YOU can write about 100 lines of code in about the same time it would take me to get sc.ini to work properly? There is a multiplicative factor here. If you do the work then it saves N people N hours of there life. If I do it, it wastes 1 hr of my life and helps no one! Please don't be a life thief! I know it takes your own life-hours to implement the code but you are the head D hauncho! Maybe hire someone or ask someone? You seem to have a following! If I actually knew what sc.ini really needed to work properly then I might do it myself, but it looks kinda crappy old win3.1 style stuff that never made much sense in the first place.
Jan 23
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/23/2016 3:49 PM, Igor wrote:
 Yes, But why do you expect me to be so smart or have a desire to waste my time
 looking for paths and such when YOU can write about 100 lines of code in about
 the same time it would take me to get sc.ini to work properly?

 There is a multiplicative factor here. If you do the work then it saves N
people
 N hours of there life. If I do it, it wastes 1 hr of my life and helps no one!

 Please don't be a life thief! I know it takes your own life-hours to implement
 the code but you are the head D hauncho! Maybe hire someone or ask someone? You
 seem to have a following!
Sucking the life force from D users is all the sustenance I need.
Jan 23
parent Igor <Vladamir.I google.com> writes:
On Sunday, 24 January 2016 at 00:46:32 UTC, Walter Bright wrote:
 Sucking the life force from D users is all the sustenance I 
 need.
Lol, ok! ;) Well, Sorry, I don't have much life force to give!
Jan 23
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 23 January 2016 at 23:49:23 UTC, Igor wrote:

 Yes, But why do you expect me to be so smart or have a desire 
 to waste my time looking for paths and such when YOU can write 
 about 100 lines of code in about the same time it would take me 
 to get sc.ini to work properly?

 There is a multiplicative factor here. If you do the work then 
 it saves N people N hours of there life. If I do it, it wastes 
 1 hr of my life and helps no one!

 Please don't be a life thief! I know it takes your own 
 life-hours to implement the code but you are the head D 
 hauncho! Maybe hire someone or ask someone? You seem to have a 
 following!

 If I actually knew what sc.ini really needed to work properly 
 then I might do it myself, but it looks kinda crappy old win3.1 
 style stuff that never made much sense in the first place.
If editing a configuration file is so difficult, you should use the installer. It will find your Microsoft tool installations and configure everything for you.
Jan 23
parent reply Igor <Vladamir.I google.com> writes:
On Sunday, 24 January 2016 at 02:59:02 UTC, Mike Parker wrote:
 On Saturday, 23 January 2016 at 23:49:23 UTC, Igor wrote:
 If editing a configuration file is so difficult, you should use 
 the installer. It will find your Microsoft tool installations 
 and configure everything for you.
Please don't parrot! I, Of course, used the installer and it didn't work, else why would I be here? The installer is obviously flawed, if you looked in to this you would see that it is the case.
Jan 23
parent Mike Parker <aldacron gmail.com> writes:
On Sunday, 24 January 2016 at 05:16:06 UTC, Igor wrote:
 Please don't parrot! I, Of course, used the installer and it 
 didn't work, else why would I be here? The installer is 
 obviously flawed, if you looked in to this you would see that 
 it is the case.
When you said, "I installed Dmd2 from scratch", I took that coupled with your problems to mean that you installed manually. My mistake.
Jan 23
prev sibling parent reply Brad Anderson <eco gnuk.net> writes:
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).
Jan 23
parent reply Igor <Vladamir.I google.com> writes:
On Sunday, 24 January 2016 at 05:34:18 UTC, Brad Anderson wrote:
 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.
Ok, I hope that it will be fixed because it seems like a rather simple issue(location issue). I can't know if there are any other problems until it is fixed.
 [snip]
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).
Ok, I think you need to use all the reg keys in HKLM "Software\Microsoft\Windows Kits\Installed Roots" and search all valid paths for the proper files. In my case, if that was done, it would find the proper library files. Basically any subdirectory that has a lib file is a possible candidate for a lib path. This is the part! The hard part is to figure out which are the "correct" libs. One can check the libs for architecture. 32-bit libs folders are candidates for the 32-bit build and ditto for 64-bit. Out of those, one should determine debug versions and separate that, even though sc.ini doesn't seem to have this capability. Maybe it could be added and then dmd can choose the correct path for debug builds. After than, one will have duplicates due to versioning. One could try and partition down further, take the latest version, or present the user with options at this point. At the very least, the installer could add all possible path candidates to the sc.ini as comments so when one goes in and edits the file, they just have to try one at a time and not go bonkers looking for the paths. Also, allow the option to copy the lib files(and possibly VC linker files) into a subfolder to use instead. This way one can avoid even having to reinstall the kits or could uninstall them and still retain the libraries outside of the VS mess. This would avoid having to have multiple VS versions installed. A simple sc.ini reconfiguration tool or re-install/modify could then be used to select the different build varieties.
Jan 24
parent Igor <Vladamir.I google.com> writes:
On Sunday, 24 January 2016 at 08:27:43 UTC, Igor wrote:
 On Sunday, 24 January 2016 at 05:34:18 UTC, Brad Anderson wrote:
[...]
Ok, I hope that it will be fixed because it seems like a rather simple issue(location issue). I can't know if there are any other problems until it is fixed. [...]
When I added 'LIB=%LIB%;"C:\PF\Windows\Kits\10\Lib\10.0.10586.0\ucrt\x64"' to sc.ini, I was able to compile. The installer is not adding this path. The installer is not functioning properly for latest VS. By scanning for these folders, it should work. The installer needs a more generic and intelligent path finding system than the somewhat hard coded one it uses now. This will make it easier to maintain in the years to come.
Jan 25