I have, and have had for some time: using msvc : 14.0 : "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe" ; In my user-config.jam However, with current develop this leads to the linker step always failing: msvc.manifest ..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0s11\debug\address-model-64\link-static\runtime-link-static\config_info.exe 'mt' is not recognized as an internal or external command, operable program or batch file. if exist "..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0s11\debug\address-model-64\link-static\runtime-link-static\config_info.exe.manifest" ( call "..\..\..\bin.v2\standalone\msvc\msvc-14.0s11\address-model-64\architecture-x86\msvc-setup.bat" amd64 >nul mt -nologo -manifest "..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0s11\debug\address-model-64\link-static\runtime-link-static\config_info.exe.manifest" "-outputresource:..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0s11\debug\address-model-64\link-static\runtime-link-static\config_info.exe;1" ) As you can see no tool name is set on the start of the command line. Anyone any ideas? Thanks! John. --- This email has been checked for viruses by AVG. http://www.avg.com
AMDG On 02/04/2018 11:13 AM, John Maddock via Boost wrote:
I have, and have had for some time:
using msvc : 14.0 : "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe" ;
Does it work if you add <rewrite-setup-scripts>off (as the next argument after the compiler)?
In my user-config.jam
However, with current develop this leads to the linker step always failing:
msvc.manifest ..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0s11\debug\address-model-64\link-static\runtime-link-static\config_info.exe
'mt' is not recognized as an internal or external command, operable program or batch file.
if exist "..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0s11\debug\address-model-64\link-static\runtime-link-static\config_info.exe.manifest" ( call "..\..\..\bin.v2\standalone\msvc\msvc-14.0s11\address-model-64\architecture-x86\msvc-setup.bat" amd64 >nul mt -nologo -manifest "..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0s11\debug\address-model-64\link-static\runtime-link-static\config_info.exe.manifest" "-outputresource:..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0s11\debug\address-model-64\link-static\runtime-link-static\config_info.exe;1"
)
As you can see no tool name is set on the start of the command line.
Anyone any ideas?
The command line looks right. Check the contents of msvc-setup.bat. In Christ, Steven Watanabe
On 04/02/2018 18:25, Steven Watanabe via Boost wrote:
AMDG
On 02/04/2018 11:13 AM, John Maddock via Boost wrote:
I have, and have had for some time:
using msvc : 14.0 : "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe" ;
Does it work if you add <rewrite-setup-scripts>off (as the next argument after the compiler)?
No, it calls vcvarsall.bat at expected, but the call to mt still fails. Strangely, if I open a VS command prompt from the start menu, then mt definitely is working. Ah... I see, that calls "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\VsDevCmd.bat" which does set the paths correctly for the SDK tools, where as vcvarsall.bat only fixes up the compiler tools, not the SDK stuff it seems. BTW the setup script sets the path to include for example: C:\Program Files (x86)\Windows Kits\10\bin\x86 But there's nothing in there.... mt.exe is located under (for example) C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x86 Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com
AMDG On 02/04/2018 12:23 PM, John Maddock via Boost wrote:
On 04/02/2018 18:25, Steven Watanabe via Boost wrote:
On 02/04/2018 11:13 AM, John Maddock via Boost wrote:
I have, and have had for some time:
using msvc : 14.0 : "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe" ;
In theory, you shouldn't need to pass the compiler path explicitly.
Does it work if you add <rewrite-setup-scripts>off (as the next argument after the compiler)?
No, it calls vcvarsall.bat at expected, but the call to mt still fails.
Strangely, if I open a VS command prompt from the start menu, then mt definitely is working. Ah... I see, that calls "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\VsDevCmd.bat" which does set the paths correctly for the SDK tools, where as vcvarsall.bat only fixes up the compiler tools, not the SDK stuff it seems.
They should both call the same code (which queries the registry). However, for me, it looks like VsDevCmd.bat sets up a 32-bit environment, while you seem to be building for 64-bit. vsvars64.bat: @call "%VS140COMNTOOLS%VCVarsQueryRegistry.bat" No32bit 64bit %1 %2 VsDevCmd.bat: @call "%VS140COMNTOOLS%VCVarsQueryRegistry.bat" 32bit No64bit
BTW the setup script sets the path to include for example:
C:\Program Files (x86)\Windows Kits\10\bin\x86
But there's nothing in there.... mt.exe is located under (for example)
C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x86
This should be x64 not x86. In Christ, Steven Watanabe
They should both call the same code (which queries the registry). However, for me, it looks like VsDevCmd.bat sets up a 32-bit environment, while you seem to be building for 64-bit.
Apologies, I tried both options and got the report a mixture of the two :( Looking into this further, some of the start menu command prompt scripts work (as in support mt) and some don't.... looks like I need to try reinstalling. Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com
Looking into this further, some of the start menu command prompt scripts work (as in support mt) and some don't.... looks like I need to try reinstalling.
Confirmed that that fixed it: looks like my msvc-14.0 install got messed up by msvc-15.x at some point :( Apologies for the noise, thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com
On 5 February 2018 at 06:07, John Maddock via Boost <boost@lists.boost.org> wrote:
Looking into this further, some of the start menu command prompt scripts
work (as in support mt) and some don't.... looks like I need to try reinstalling.
Confirmed that that fixed it: looks like my msvc-14.0 install got messed up by msvc-15.x at some point :(
For a while, I ran vs2015 and vs2017 alongside each other (officially supported setup) and it became messy. In the end I did like you, I ditched vs2015 and reinstalled vs2017, no issues! degski
On 2/5/2018 8:11 AM, degski via Boost wrote:
On 5 February 2018 at 06:07, John Maddock via Boost <boost@lists.boost.org> wrote:
Looking into this further, some of the start menu command prompt scripts
work (as in support mt) and some don't.... looks like I need to try reinstalling.
Confirmed that that fixed it: looks like my msvc-14.0 install got messed up by msvc-15.x at some point :(
For a while, I ran vs2015 and vs2017 alongside each other (officially supported setup) and it became messy. In the end I did like you, I ditched vs2015 and reinstalled vs2017, no issues!
FWIW, I have to use both 2017 and 2015. Consequently, I always manually open a dedicated Visual Studio command prompt for x86, x64, VS2015, VS2017 as appropriate. Plus with VS2017, many of the directory paths to reach the various support files and executables are too long. I have a permanent link with mklink that is C:\v7 = "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise" --Robert
degski
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 5 February 2018 at 09:43, Robert via Boost <boost@lists.boost.org> wrote:
... Plus with VS2017, many of the directory paths to reach the various support files and executables are too long.
If you are on Windows 10, you can just remove the path length restriction permanently by following the instructions posted here <https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/> . degski
On 2/5/2018 10:24 AM, degski via Boost wrote:
On 5 February 2018 at 09:43, Robert via Boost <boost@lists.boost.org> wrote:
... Plus with VS2017, many of the directory paths to reach the various support files and executables are too long.
If you are on Windows 10, you can just remove the path length restriction permanently by following the instructions posted here <https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/> .
I am on Windows 8.1 Pro, x64. Sorry about not writing that before. --Robert
degski
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2/8/2018 2:20 PM, degski via Boost wrote:
On 8 February 2018 at 14:00, Robert via Boost <boost@lists.boost.org> wrote:
I am on Windows 8.1 Pro, x64.
A shame you missed the free upgrade!
Not exactly missed. I remain on it as part of the team effort to support the customers' Windows operating system versions. There are many times we find problems on certain combinations of OS and Office. Then, no issues on other combinations. --Robert
degski
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
For a while, I ran vs2015 and vs2017 alongside each other (officially supported setup) and it became messy. In the end I did like you, I ditched vs2015 and reinstalled vs2017, no issues!
Like you I've been using VS2017 exclusively, but for testing Boost stuff nothing beats having a whole bunch of compilers installed locally.... I just hadn't noticed that VS2015 had become broken until now. Best, John. --- This email has been checked for viruses by AVG. http://www.avg.com
On 5 Feb 2018, at 18:29, John Maddock via Boost <boost@lists.boost.org> wrote:
For a while, I ran vs2015 and vs2017 alongside each other (officially supported setup) and it became messy. In the end I did like you, I ditched vs2015 and reinstalled vs2017, no issues!
Like you I've been using VS2017 exclusively, but for testing Boost stuff nothing beats having a whole bunch of compilers installed locally….
It is not clear to me why you need both VS2015 and VS2017 installed to have a bunch of compilers locally. VS2017 installer gives you the option of installing older compilers as additional toolkits. This give you additional Visual Studio 2015 Cross Tools Command Prompts and all. I don’t think this is supported for compilers from VS2012 and older, so in that case you need to install them separately. — Bjørn
On 7 February 2018 at 13:40, Bjørn Roald via Boost <boost@lists.boost.org> wrote:
It is not clear to me why you need both VS2015 and VS2017 installed to have a bunch of compilers locally.
Nobody is saying that. We discussed the situation, first having installed VS2015 (with over time (after updates) a number of different SDK's) and consequently installing VS2017, without uninstalling VS2015. This config appears to have some issues. From the mouth of STL (as per reddit.com/r/cpp/ and some posts here): "VS2015 is no longer recommended under any circumstance." The "bunch of compilers" should be limited to 10.0.16299.0 (or VC-15.5.5), iff you are using anything newer than VS2013. degski
participants (5)
-
Bjørn Roald -
degski -
John Maddock -
Robert -
Steven Watanabe