Develop is broken on MSVC (b2 issue?)
I see a bunch of CI failures https://apolukhin.github.io/en/developer.html for different versions of MSVC. There are some complains on 'cl': compile-c-c++ ..\..\..\bin.v2\libs\type_index\test\track_13621.test\msvc-9.0\release\threading-multi\track_13621.obj 'cl' is not recognized as an internal or external command, operable program or batch file. call "..\..\..\bin.v2\standalone\msvc\msvc-9.0\msvc-setup.bat" amd64 >nul cl /Zm800 -nologo "track_13621.cpp" -Fo"..\..\..\bin.v2\libs\type_index\test\track_13621.test\msvc-9.0\release\threading-multi\track_13621.obj" -TP -DBOOST_TRAVISCI_BUILD /wd4675 /EHs /GR /O2 /Ob2 /W3 /MD /Zc:forScope /Zc:wchar_t /favor:blend -c -DBOOST_ALL_NO_LIB=1 -DNDEBUG "-I..\..\.." ...failed compile-c-c++ ..\..\..\bin.v2\libs\type_index\test\track_13621.test\msvc-9.0\release\threading-multi\track_13621.obj... Is that a known issue?
Antony Polukhin wrote:
I see a bunch of CI failures https://apolukhin.github.io/en/developer.html for different versions of MSVC. There are some complains on 'cl':
compile-c-c++ ..\..\..\bin.v2\libs\type_index\test\track_13621.test\msvc-9.0\release\threading-multi\track_13621.obj 'cl' is not recognized as an internal or external command, operable program or batch file.
You need to pass address-model=32. The default is now 64 bit (inferred from PROCESSOR_ARCHITECTURE=AMD64 AFAICS), and not all Appveyor MSVC versions support 64 bit.
On 1/3/21 9:12 PM, Peter Dimov via Boost wrote:
Antony Polukhin wrote:
I see a bunch of CI failures https://apolukhin.github.io/en/developer.html for different versions of MSVC. There are some complains on 'cl':
compile-c-c++ ..\..\..\bin.v2\libs\type_index\test\track_13621.test\msvc-9.0\release\threading-multi\track_13621.obj
'cl' is not recognized as an internal or external command, operable program or batch file.
You need to pass address-model=32. The default is now 64 bit (inferred from PROCESSOR_ARCHITECTURE=AMD64 AFAICS), and not all Appveyor MSVC versions support 64 bit.
Default address-model and architecture get misdetected as "none" in some cases and 64-bit x86 in others on the same machine. This is a regression in Boost.Build that appeared quite some time ago. https://github.com/boostorg/build/issues/659 As you said, the workaround is to explicitly specify these features in the command line.
participants (3)
-
Andrey Semashev -
Antony Polukhin -
Peter Dimov