digitalmars.D - Dmd sc.ini and VS do not work well together!
- Igor (72/72) Jan 23 2016 I feel like I am in the cave man times. I installed Dmd2 from
- Igor (7/14) Jan 23 2016 These should be placed here instead of the individual sections as
- Walter Bright (2/3) Jan 23 2016 You know, sc.ini is editable by you!
- Igor (14/17) Jan 23 2016 Yes, But why do you expect me to be so smart or have a desire to
- Walter Bright (2/10) Jan 23 2016 Sucking the life force from D users is all the sustenance I need.
- Igor (2/4) Jan 23 2016 Lol, ok! ;) Well, Sorry, I don't have much life force to give!
- Mike Parker (4/18) Jan 23 2016 If editing a configuration file is so difficult, you should use
- Igor (5/9) Jan 23 2016 Please don't parrot! I, Of course, used the installer and it
- Mike Parker (4/8) Jan 23 2016 When you said, "I installed Dmd2 from scratch", I took that
- Brad Anderson (30/54) Jan 23 2016 Sorry you are having trouble. The Universal CRT and Visual Studio
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 2016
Igor <Vladamir.I google.com> 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 2016
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 2016
On Saturday, 23 January 2016 at 22:47:35 UTC, Walter Bright wrote:On 1/23/2016 1:38 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! 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.As of now I personally cannot use dmd to build windows apps.You know, sc.ini is editable by you!
Jan 23 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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.0We 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 2016
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: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.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 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.[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).
Jan 24 2016
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: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.[...]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. [...]
Jan 25 2016