Bug 11266 – Ship new sc.ini with expanded support for more versions of Visual Studio/Windows SDK

Created attachment 1264 New sc.ini Attached is the new sc.ini I'd like which is compatible with the Window's installer's sc.ini rewriting. Here it is inline for easy reference: --- [Version] version=7.51 Build 020 [Environment] DFLAGS="-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import" [Environment32] LIB="%@P%\..\lib";\dm\lib LINKCMD=%@P%\link.exe [Environment64] LIB=%VCINSTALLDIR%lib\amd64;%WindowsSdkDir%lib\x64;"%@P%\..\lib";\dm\lib; LINKCMD=%VCINSTALLDIR%bin\amd64\link.exe ---

Requires: https://github.com/D-Programming-Language/dmd/pull/2667

If pull request 2667 doesn't get merged this can still be used but LINKCMD in the Environment64 section must be changed to LINKCMD64.

I think you should not include \dm\lib in sc.ini. It is pretty uncommon to have this directory and it does not work across multiple drives. It is even harmful for win64 as there are no 64-bit libraries in the dm folders.

(In reply to comment #3) > I think you should not include \dm\lib in sc.ini. It is pretty uncommon to have > this directory and it does not work across multiple drives. > > It is even harmful for win64 as there are no 64-bit libraries in the dm > folders. Ok, will remove. I need to add PATH to this so VS2012/2013's LINKCMD will work too so this isn't ready in it's current state.

I've suggested a slightly more elaborate version of sc.ini here: http://forum.dlang.org/thread/20130903205311.00003c40@unknown?page=5#post-l10vtc:2476o:241:40digitalmars.com Just adding all possible library paths for the different SDKs should do the trick to support different installations.

(In reply to comment #5) > I've suggested a slightly more elaborate version of sc.ini here: > http://forum.dlang.org/thread/20130903205311.00003c40@unknown?page=5#post-l10vtc:2476o:241:40digitalmars.com > > Just adding all possible library paths for the different SDKs should do the > trick to support different installations. Do you see any harm in(In reply to comment #5) > I've suggested a slightly more elaborate version of sc.ini here: > http://forum.dlang.org/thread/20130903205311.00003c40@unknown?page=5#post-l10vtc:2476o:241:40digitalmars.com > > Just adding all possible library paths for the different SDKs should do the > trick to support different installations. So you are saying something like (modified slightly)?: --- ; environment for both 32/64 bit [Environment] LIB="%@P%\..\lib" DFLAGS="-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import" [Environment32] LINKCMD=%@P%\link.exe [Environment64] ; VS2010 ;VS2010LINKCMD=%VCINSTALLDIR%\bin\amd64\link.exe ; VS2012 ;VS2012LINKCMD=%VCINSTALLDIR%\bin\x86_amd64\link.exe ; needed with /DEBUG to find mspdb*.dll ;VS2012PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\..\Common7\IDE ; VS2013 ;VS2013LINKCMD=%VCINSTALLDIR%\bin\x86_amd64\link.exe ; needed with /DEBUG to find mspdb*.dll ;VS2013PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\..\Common7\IDE ; needed to avoid COMDAT folding (bugzilla 10664) DFLAGS=%DFLAGS% -L/OPT:NOICF LIB="%@P%\..\lib64" ;;;; search path for C Runtime libraries ; the following lib path works with VS2008, VS2010 and VS2012 LIB=%LIB%;"%VCINSTALLDIR%\lib\amd64" ;;;; search path for Platform libraries ; the following lib path works with Windows SDK 6.x and 7.x LIB=%LIB%;%WindowsSdkDir%\Lib\x64 ; the following lib path works with Windows SDK 8.0 LIB=%LIB%;%WindowsSdkDir%\Lib\win8\um\x64 --- The VS{2010,2012,2013}{LINKCMD,PATH} business is because the way the installer does things is by simple find and replace so that'd make those easy to enable. If you see no harm in having the LIB for every version active that'd certainly make things easier. Optlink is never valid in 64 so I moved the LINKCMD for it to 32 (do you see any problems with that)? Any tips for getting this working with Express? If I remember correctly a person need a specific version of the platform SDK to get the necessary command line tools but I can't remember the details beyond that.

(In reply to comment #6) > The VS{2010,2012,2013}{LINKCMD,PATH} business is because the way the installer > does things is by simple find and replace so that'd make those easy to enable. > If you see no harm in having the LIB for every version active that'd certainly > make things easier. If LINKCMD is patched by the installer, I'm fine with it. But how does the sc.ini in the zip file look like? I don't have a solution to making it work with both VS2010 and VS2012 yet. > > Optlink is never valid in 64 so I moved the LINKCMD for it to 32 (do you see > any problems with that)? That should be no problem. > Any tips for getting this working with Express? If I remember correctly a > person need a specific version of the platform SDK to get the necessary command > line tools but I can't remember the details beyond that. I haven't used the Express versions recently, but IIRC VS2012 Express installation was very similar to the full version, while VS2010 Express never had x64 support. You had to install the Windows 7 SDK to get the x64 tool chain.

(In reply to comment #3) > I think you should not include \dm\lib in sc.ini. It is pretty uncommon to have > this directory and it does not work across multiple drives. > > It is even harmful for win64 as there are no 64-bit libraries in the dm > folders. Do we still need dmc's lib folder on Win32? There is an old Bug 459 that mentiones removing \dm\lib too.

(In reply to comment #7) > (In reply to comment #6) > > The VS{2010,2012,2013}{LINKCMD,PATH} business is because the way the installer > > does things is by simple find and replace so that'd make those easy to enable. > > If you see no harm in having the LIB for every version active that'd certainly > > make things easier. > > If LINKCMD is patched by the installer, I'm fine with it. But how does the > sc.ini in the zip file look like? I don't have a solution to making it work > with both VS2010 and VS2012 yet. > It'd look just like above. If neither LINKCMD64 nor LINKCMD64 is found dmd just uses "link". I believe this means it'll still work if someone just runs the usual vcvarsall.bat to get the MSVC toolset in the PATH (if they installed MSVC after dmd, for instance). vcvarsall.bat prepends to the PATH so optlink shouldn't get in the way in this case. vcvarsall.bat is already required for the current sc.ini so this should be functionally no different then what we have now.

Here's what I've come to: --- [Version] version=7.51 Build 020 ; environment for both 32/64 bit [Environment] DFLAGS="-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import" [Environment32] LIB="%@P%\..\lib" LINKCMD=%@P%\link.exe [Environment64] ; VS2010 ;VS2010LINKCMD=%VCINSTALLDIR%bin\amd64\link.exe ; VS2012 ;VS2012LINKCMD=%VCINSTALLDIR%bin\x86_amd64\link.exe ; needed with /DEBUG to find mspdb*.dll ;VS2012PATH=%PATH%;%VCINSTALLDIR%bin\x86_amd64;%VCINSTALLDIR%..\Common7\IDE ; VS2013 ;VS2013LINKCMD=%VCINSTALLDIR%bin\x86_amd64\link.exe ; needed with /DEBUG to find mspdb*.dll ;VS2013PATH=%PATH%;%VCINSTALLDIR%bin\x86_amd64;%VCINSTALLDIR%..\Common7\IDE ; needed to avoid COMDAT folding (bugzilla 10664) DFLAGS=%DFLAGS% -L/OPT:NOICF LIB="%@P%\..\lib64";"%@P%\..\lib" ;;;; search path for C Runtime libraries ; the following lib path works with VS2008, VS2010, VS2012, VS2013 ; prepending because 32-bit OMF versions can cause link.exe to fail LIB="%VCINSTALLDIR%lib\amd64";%LIB% ;;;; search path for Platform libraries ; the following lib path works with Windows SDK 6.x and 7.x LIB="%WindowsSdkDir%Lib\x64";%LIB% ; the following lib path works with Windows SDK 8.0 and 8.1 LIB="%WindowsSdkDir%Lib\win8\um\x64";%LIB% --- I've moved LIB out of Environment (separate entries for 32 and 64) so I could stick %@P%\..\lib after %@P%\..\lib64 (if nothing else this should allow me to get 64-bit curl working). I had to prepend the VC/SDK search paths so that the 32-bit OMF libraries in ..\lib don't break link.exe (if we get to where we can remove %@P%\..\lib from Environment64 these can go back to being appended to LIB).

Created attachment 1266 New sc.ini (try 2)

(In reply to comment #9) > It'd look just like above. If neither LINKCMD64 nor LINKCMD64 is found dmd just > uses "link". I believe this means it'll still work if someone just runs the > usual vcvarsall.bat to get the MSVC toolset in the PATH (if they installed MSVC > after dmd, for instance). vcvarsall.bat prepends to the PATH so optlink > shouldn't get in the way in this case. vcvarsall.bat is already required for > the current sc.ini so this should be functionally no different then what we > have now. If you have run vcvarsall.bat, VCINSTALLDIR is set and dmd uses VCINSTALLDIR to create a non-working path to link.exe for VS2012+ instead of using just "link": Can't run 'c:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64\link ', check PATH If you haven't run vcvarsall.bat, VCINSTALLDIR is not set, but also PATH doesn't contain the VC bin directory, so it will probably pick up optlink when running "link".

> LIB="%VCINSTALLDIR%lib\amd64";%LIB% Please add '\' between the variable and lib. For some installations on my system there is no trailing '\' in the environment variable, probably because I have changed the destination path during installation. A double back slash causes no problems, but a missing one does.

I always wanted to try whether the 32-bit MS linker is able to build 64-bit executables, and it actually is! So the linker setting can just be LINKCMD=%VCINSTALLDIR%\bin\link.exe

The current sc.ini: https://github.com/D-Programming-Language/dmd/pull/2674 After this is pulled, revised one can be done as PR's.

(In reply to comment #15) > The current sc.ini: > > https://github.com/D-Programming-Language/dmd/pull/2674 > > After this is pulled, revised one can be done as PR's. Thanks, Walter. That's much easier.

(In reply to comment #13) > > LIB="%VCINSTALLDIR%lib\amd64";%LIB% > > Please add '\' between the variable and lib. For some installations on my > system there is no trailing '\' in the environment variable, probably because I > have changed the destination path during installation. A double back slash > causes no problems, but a missing one does. Done (I was wondering why those were there).

(In reply to comment #14) > I always wanted to try whether the 32-bit MS linker is able to build 64-bit > executables, and it actually is! So the linker setting can just be > > LINKCMD=%VCINSTALLDIR%\bin\link.exe I think I'll stick with the 64-bit since they already work. I have occasional problems with the 32-bit toolset in Visual Studio in my C++ projects at work (big PCH and Whole Program Optimization can trigger it) and I know these problems don't occur in the 64-bit toolset.

(In reply to comment #18) > (In reply to comment #14) > > I always wanted to try whether the 32-bit MS linker is able to build 64-bit > > executables, and it actually is! So the linker setting can just be > > > > LINKCMD=%VCINSTALLDIR%\bin\link.exe > > I think I'll stick with the 64-bit since they already work. I have occasional > problems with the 32-bit toolset in Visual Studio in my C++ projects at work > (big PCH and Whole Program Optimization can trigger it) and I know these > problems don't occur in the 64-bit toolset. Actually, on second thought I'll throw that in there as a backup that gets overridden in case the installer doesn't detect VS.

Created attachment 1268 New sc.ini (try 3)

Just attached a new version which I feel a lot better about. Simpler for the installer to modify and should work with all versions of the VS Command Prompt. It's also much easier for end users to manually configure. Here it is inline: --- [Version] version=7.51 Build 020 ; environment for both 32/64 bit [Environment] DFLAGS="-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import" [Environment32] LIB="%@P%\..\lib" LINKCMD=%@P%\link.exe [Environment64] LIB="%@P%\..\lib64" ; needed to avoid COMDAT folding (bugzilla 10664) DFLAGS=%DFLAGS% -L/OPT:NOICF ; default to 32-bit linker (can generate 64-bit code) that has a common path ; for VS2010, VS2012, and VS2013. This will be overridden below if the ; installer detects VS. LINKCMD=%VCINSTALLDIR%\bin\link.exe ; ----------------------------------------------------------------------------- ; This enclosed section is specially crafted to be activated by the Windows ; installer when it detects the actual paths to VC and SDK installations so ; modify this in the default sc.ini within the git repo with care ; ; End users: You can fill in the path to VC and Windows SDK and uncomment out ; the appropriate LINKCMD to manually enable support ; Windows installer replaces the following lines with the actual paths ;VCINSTALLDIR= ;WindowsSdkDir= ; Windows installer uncomments the version detected ;VC2013 LINKCMD=%VCINSTALLDIR%\bin\x86_amd64\link.exe ;VC2012 LINKCMD=%VCINSTALLDIR%\bin\x86_amd64\link.exe ;VC2010 LINKCMD=%VCINSTALLDIR%\bin\amd64\link.exe ; ---------------------------------------------------------------------------- ; needed with /DEBUG to find mspdb*.dll (only for VS2012 or VS2013) PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\..\Common7\IDE PATH=%PATH%;%VCINSTALLDIR%\..\Common7\IDE ; Add the library subdirectories of all VC and Windows SDK versions so things ; just work for users using dmd from the VS 64-bit Command Prompt ; C Runtime libraries LIB=%LIB%;"%VCINSTALLDIR%\lib\amd64" ; Platform libraries (Windows SDK 8) LIB=%LIB%;"%WindowsSdkDir%\Lib\win8\um\x64" ; Platform libraries (Windows SDK 7) LIB=%LIB%;"%WindowsSdkDir%\Lib\x64" ---

Looks nice. One more nitpick: > ; needed with /DEBUG to find mspdb*.dll (only for VS2012 or VS2013) > PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\..\Common7\IDE > PATH=%PATH%;%VCINSTALLDIR%\..\Common7\IDE This adds %VCINSTALLDIR%\..\Common7\IDE twice. With running the 32-bit linker, adding an x64 path to PATH might be troublesome. I currently don't have a full VS2012 installation to test whether it actually causes problems.

(In reply to comment #22) > Looks nice. One more nitpick: > > > ; needed with /DEBUG to find mspdb*.dll (only for VS2012 or VS2013) > > PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\..\Common7\IDE > > PATH=%PATH%;%VCINSTALLDIR%\..\Common7\IDE > > This adds %VCINSTALLDIR%\..\Common7\IDE twice. > Oops. > With running the 32-bit linker, adding an x64 path to PATH might be > troublesome. I currently don't have a full VS2012 installation to test whether > it actually causes problems. I originally had those enabled by the installer but decided to just define them always instead to keep the number of changes the compiler must do to a minimum. I'll make those enabled by the installer again in the next iteration.

(In reply to comment #21) > [Environment32] > LIB="%@P%\..\lib" > LINKCMD=%@P%\link.exe I just noticed that calling optlink directly is affected by this change as it also reads LIB from the [Environment] section in sc.ini. Ugly, but I guess we should add the LIB setting there, too.

(In reply to comment #24) > (In reply to comment #21) > > [Environment32] > > LIB="%@P%\..\lib" > > LINKCMD=%@P%\link.exe > > I just noticed that calling optlink directly is affected by this change as it > also reads LIB from the [Environment] section in sc.ini. Ugly, but I guess we > should add the LIB setting there, too. I'm glad you noticed that. I'll incorporate it.

Created attachment 1271 New sc.ini (try 4) Attached is what I think is the final version. I'll make it into a pull request shortly. Inline: --- [Version] version=7.51 Build 020 ; environment for both 32/64 bit [Environment] DFLAGS="-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import" ; optlink only reads from the Environment section so we need this redundancy ; from the Environment32 section (bugzilla 11302) LIB="%@P%\..\lib" [Environment32] LIB="%@P%\..\lib" LINKCMD=%@P%\link.exe [Environment64] LIB="%@P%\..\lib64" ; needed to avoid COMDAT folding (bugzilla 10664) DFLAGS=%DFLAGS% -L/OPT:NOICF ; default to 32-bit linker (can generate 64-bit code) that has a common path ; for VS2008, VS2010, VS2012, and VS2013. This will be overridden below if the ; installer detects VS. LINKCMD=%VCINSTALLDIR%\bin\link.exe ; ----------------------------------------------------------------------------- ; This enclosed section is specially crafted to be activated by the Windows ; installer when it detects the actual paths to VC and SDK installations so ; modify this in the default sc.ini within the dmd git repo with care. ; ; End users: You can fill in the path to VC and Windows SDK and uncomment out ; the appropriate LINKCMD to manually enable support yourself. ; ; Users using Visual Studio 2010 Express with SDK 7.0A: The installer cannot ; determine the path to the 64-bit compiler included with SDK 7.0A. It's ; recommended to install the Windows SDK 7.1A. Alternatively you can set ; LINKCMD as the path to link.exe SDK 7.0A installs. It would typically be: ; C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\link.exe ; Windows installer replaces the following lines with the actual paths ;VCINSTALLDIR= ;WindowsSdkDir= ; - Windows installer uncomments the version detected ;VC2013 LINKCMD=%VCINSTALLDIR%\bin\x86_amd64\link.exe ;VC2012 LINKCMD=%VCINSTALLDIR%\bin\x86_amd64\link.exe ;VC2010 LINKCMD=%VCINSTALLDIR%\bin\amd64\link.exe ;VC2008 LINKCMD=%VCINSTALLDIR%\bin\amd64\link.exe ; needed with /DEBUG to find mspdb*.dll (only for VS2012 or VS2013) ;VC2013 PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\..\Common7\IDE ;VC2012 PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\..\Common7\IDE ; ---------------------------------------------------------------------------- ; Add the library subdirectories of all VC and Windows SDK versions so things ; just work for users using dmd from the VS 64-bit Command Prompt ; C Runtime libraries LIB=%LIB%;"%VCINSTALLDIR%\lib\amd64" ; Platform libraries (Windows SDK 8) LIB=%LIB%;"%WindowsSdkDir%\Lib\win8\um\x64" ; Platform libraries (Windows SDK 7 and 6) LIB=%LIB%;"%WindowsSdkDir%\Lib\x64" ---

Commit pushed to 2.064 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/2d11aa4311eb2356c759dcd5fa38b046adbb11de New sc.ini with expanded 64-bit support Note: Requires phobos64.lib to be in lib64 rather than lib Fixes issue #11266 Should work for all versions of Visual Studio 2008+ when dmd is used within the Visual Studio Command Prompt. Works in conjunction with the Windows dmd installer to automatically set appropriate paths so 64-bit dmd compilation can be used outside of the Visual Studio Command Prompt

Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a1a8852988aed7b7f685931fbe2dee58ffc89852 New sc.ini with expanded 64-bit support Note: Requires phobos64.lib to be in lib64 rather than lib Fixes issue #11266 Should work for all versions of Visual Studio 2008+ when dmd is used within the Visual Studio Command Prompt. Works in conjunction with the Windows dmd installer to automatically set appropriate paths so 64-bit dmd compilation can be used outside of the Visual Studio Command Prompt