[boost] [build] msvc-14 linker step failing?
John Maddock via Boost
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Steven Watanabe via Boost
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
John Maddock via Boost
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
Steven Watanabe via Boost
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
John Maddock via Boost
> 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.
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.
John Maddock via Boost
> 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.
>
up by msvc-15.x at some point :(
Apologies for the noise, thanks, John.
degski via Boost
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 :(
supported setup) and it became messy. In the end I did like you, I ditched
vs2015 and reinstalled vs2017, no issues!
degski
Robert via Boost
> On 5 February 2018 at 06:07, John Maddock via Boost <bo...@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!
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 via Boost
> ... Plus with VS2017, many of the directory paths to reach the various
permanently by following the instructions posted here
<https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/>
.
John Maddock via 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!
nothing beats having a whole bunch of compilers installed locally.... I
just hadn't noticed that VS2015 had become broken until now.
Best, John.
Bjørn Roald via Boost
> On 5 Feb 2018, at 18:29, John Maddock via Boost <bo...@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!
>
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
degski via Boost
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
Robert via Boost
> On 5 February 2018 at 09:43, Robert via Boost <bo...@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/>
> .
--Robert
degski via Boost
> I am on Windows 8.1 Pro, x64.
>
Robert via Boost
> On 8 February 2018 at 14:00, Robert via Boost <bo...@lists.boost.org> wrote:
>
>> I am on Windows 8.1 Pro, x64.
>>
>
> A shame you missed the free upgrade!
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