clang tidy emits errors about exceptions being disabled when the are enabled - visual-c++

I enabled clang-tidy integration to a CMake project like so:
set(CMAKE_CXX_CLANG_TIDY
clang-tidy;
-header-filter=.;
--config-file=${MY_CLANG_TIDY_CONFIG_PATH};
)
In the .clang-tidy config file, there are rules for checking naming conventions only.
After generating the project and trying to build one one of the targets, I get an error from clang claiming exceptions are used even though disabled.
This is the command I run and its output:
cmake --build --preset=ninja-wd --target=Eureka.Core
output:
[1/3] Building CXX object Libs\Eureka.Core\CMakeFiles\Eureka.Core.dir\system.cpp.obj
FAILED: Libs/Eureka.Core/CMakeFiles/Eureka.Core.dir/system.cpp.obj
"C:\Program Files\CMake\bin\cmake.exe" -E __run_co_compile --tidy=clang-tidy;-header-filter=.;--config-file=C:/workspace/Eureka/.clang-tidy;--extra-arg-before=--driver-mode=cl --source=C:\workspace\Eureka\Libs\Eureka.Core\system.cpp -- C:\PROGRA~1\MICROS~2\2022\COMMUN~1\VC\Tools\MSVC\1434~1.319\bin\Hostx64\x64\cl.exe /nologo /TP -DBoost_NO_WARN_NEW_VERSIONS=1 -DEUREKA_NO_NVTOOLSEXT -DNOMINMAX -DPERFETTO_TRACING -DPROFILING_ENABLED -DWIN32_LEAN_AND_MEAN -IC:\workspace\Eureka -IC:\workspace\Eureka\Libs\Eureka.Core /DWIN32 /D_WINDOWS /EHsc /Zi /Ob0 /Od /RTC1 -MDd /permissive- /bigobj /W4 /EHsc -std:c++latest /showIncludes /FoLibs\Eureka.Core\CMakeFiles\Eureka.Core.dir\system.cpp.obj /FdLibs\Eureka.Core\CMakeFiles\Eureka.Core.dir\Eureka.Core.pdb /FS -c C:\workspace\Eureka\Libs\Eureka.Core\system.cpp
C:\workspace\Eureka\Libs\Eureka.Core\system.cpp:26:9: error: cannot use 'throw' with exceptions disabled [clang-diagnostic-error]
throw std::system_error(ec, "system error");
^
2823 warnings and 1 error generated.
Error while processing C:\workspace\Eureka\Libs\Eureka.Core\system.cpp.
Suppressed 2824 warnings (2823 in non-user code, 1 NOLINT).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
Found compiler error(s).
As far as I can see, the /EHsc flag is passed to cl.exe. And yet I get the error from clang saying
error: cannot use 'throw' with exceptions disabled [clang-diagnostic-error]
throw std::system_error(ec, "system error");
What is going on here? why is clang-tidy complaining?
If I disable the clang-tidy integration, the project builds just fine.

Related

CMake: Check existence of MSVC compiler flags

Normally, I use check_cxx_compiler_flag to check whether a given flag is recognized by the currently used compiler. However, I have run into issues with MSVC where some default flags are causing the test to fail due to incompatible flags.
MWE:
cmake_minimum_required(VERSION 3.5)
project(MWE)
include(CheckCXXCompilerFlag)
set(CMAKE_CXX_FLAGS "" CACHE INTERNAL "" FORCE)
set(CMAKE_CXX_FLAGS_DEBUG "" CACHE INTERNAL "" FORCE)
set(CMAKE_CXX_FLAGS_RELEASE "" CACHE INTERNAL "" FORCE)
set(CMAKE_CXX_FLAGS_MINSIZEREL "" CACHE INTERNAL "" FORCE)
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "" CACHE INTERNAL "" FORCE)
check_cxx_compiler_flag("/O2" FLAG_USABLE)
if (NOT FLAG_USABLE)
message(FATAL_ERROR "Flag not usable")
endif()
When this is run on Windows in a developer command prompt, the test fails and the error log contains
Run Build Command(s):C:/Program Files/Microsoft Visual Studio/2022/Enterprise/MSBuild/Current/Bin/amd64/MSBuild.exe cmTC_e3d37.vcxproj /p:Configuration=Debug /p:Platform=x64 /p:VisualStudioVersion=17.0 /v:m && MSBuild version 17.3.1+2badb37d1 for .NET Framework
Microsoft (R) C/C++ Optimizing Compiler Version 19.33.31630 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
cl /c /Zi /W1 /WX- /diagnostics:column /O2 /Ob0 /D _MBCS /D FLAG_USABLE /D "CMAKE_INTDIR=\"Debug\"" /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_e3d37.dir\Debug\\" /Fd"cmTC_e3d37.dir\Debug\vc143.pdb" /external:W1 /Gd /TP /errorReport:queue "D:\a\cmake-compiler-flags\cmake-compiler-flags\test\build\CMakeFiles\CMakeTmp\src.cxx"
cl : command line error D8016: '/O2' and '/RTC1' command-line options are incompatible
which clearly shows that the flag is recognized, but it just does not play nicely with the /RTC1 flag, which somehow still gets added to the build.
How can I get rid of these default options (or at least all that are not essential for a build to complete), regardless of the used build configuration, so that my test really checks whether the compiler understands the given flag?
I guess your IDE - Visual Studio is adding this compilation flag. Try running Cmake from command line and the problem should be solved. In order to change VS behavior go to Solution -> Properties -> Configuration Properties -> C/C++ -> Code Generation -> Basic Runtime Checks and change the value of this flag to default or disabled.

LNK1104 error with python setup.py build

I have built Quantlib on Windows using Visual Studio 2017 and want to build Quantlib-SWIG for Python.
However, I have LNK1104: error. Namely, after launching Command Prompt from C:\QuantLib-SWIG-1.12\Python directory I receive this error:
fatal error LNK1104: cannot open file 'QuantLib-vc90-x64-mt.lib'
I saw a similar question with advise from Luigi Ballabio and KingJohnno to verify if QuantLib-vc90-x64-mt.lib file is in place & add to the path variable C:\QuantLib-SWIG-1.12.
I did the last suggestion, but I have the problem with that I have in C:\QuantLib\QuantLib-1.12\lib a QuantLib-vc141-x64-mt.lib library, i.e. not the file QuantLib-vc90-x64-mt.lib. I have created separate directory with vc141 file renamed to vc90. This did not help.
I have also read online that the problem might be with the Python specifically builded using different VS version. I have downloaded Python 2.7 builded using VS 2010 (not VS2008) and did not succeed as well.
Please see the whole terminal message here:
C:\QuantLib-SWIG-1.12\Python>cd C:\QuantLib-SWIG-1.12\Python
C:\QuantLib-SWIG-1.12\Python>set QL_DIR=C:\QuantLib\QuantLib-1.12
C:\QuantLib-SWIG-1.12\Python>set INCLUDE=C:\Boost\boost_1_66_0
C:\QuantLib-SWIG-1.12\Python>
C:\QuantLib-SWIG-1.12\Python>python setup.py build
running build
running build_py
running build_ext
building 'QuantLib._QuantLib' extension
C:\Users\user1\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Bin\amd64\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -D__WIN32__ -DWIN32 -DNDEBUG -D_WINDOWS -DNOMINMAX -IC:\Python27vc08\include -IC:\Python27vc08\PC -IC:\QuantLib\QuantLib-1.12 -IC:\Boost\boost_1_66_0 /TpQuantLib/quantlib_wrap.cpp /Fobuild\temp.win-amd64-2.7\Release\QuantLib/quantlib_wrap.obj /GR /FD /Zm250 /EHsc /bigobj /MD
quantlib_wrap.cpp
C:\Users\user1\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Include\xutility(2472) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data
C:\Users\user1\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Include\xutility(2485) : see reference to function template instantiation '_OutIt std::_Copy_opt<_InIt,unsigned int*,std::forward_iterator_tag>(_InIt,_InIt,_OutIt,_InOutItCat,std::_Nonscalar_ptr_iterator_tag,std::_Range_checked_iterator_tag)' being compiled
with
[
_OutIt=unsigned int *,
_InIt=const unsigned __int64 *,
_InOutItCat=std::forward_iterator_tag
]
C:\Users\user1\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Include\xutility(2563) : see reference to function template instantiation '_OutIt std::_Copy_opt<const unsigned __int64*,_OutIt>(_InIt,_InIt,_OutIt,std::random_access_iterator_tag,std::_Nonscalar_ptr_iterator_tag,std::_Range_checked_iterator_tag)' being compiled
with
[
_OutIt=std::_Vector_iterator<std::_Vbase,std::allocator<std::_Vbase>>,
_InIt=const unsigned __int64 *
]
QuantLib/quantlib_wrap.cpp(16340) : see reference to function template instantiation 'std::_Vector_iterator<_Ty,_Alloc> std::copy<std::_Vector_const_iterator<unsigned __int64,std::allocator<unsigned __int64>>,std::_Vector_iterator<_Ty,_Alloc>>(_InIt,_InIt,_OutIt)' being compiled
with
[
_Ty=std::_Vbase,
_Alloc=std::allocator<std::_Vbase>,
_InIt=std::_Vector_const_iterator<size_t,std::allocator<size_t>>,
_OutIt=std::_Vector_iterator<std::_Vbase,std::allocator<std::_Vbase>>
]
C:\Users\user1\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Bin\amd64\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\Python27vc08\libs /LIBPATH:C:\Python27vc08\PCbuild\amd64 /LIBPATH:C:\Python27vc08\PC\VS9.0\amd64 /LIBPATH:C:\QuantLib\QuantLib-1.12\lib /EXPORT:init_QuantLib build\temp.win-amd64-2.7\Release\QuantLib/quantlib_wrap.obj /OUT:build\lib.win-amd64-2.7\QuantLib\_QuantLib.pyd /IMPLIB:build\temp.win-amd64-2.7\Release\QuantLib\_QuantLib.lib /MANIFESTFILE:build\temp.win-amd64-2.7\Release\QuantLib\_QuantLib.pyd.manifest /subsystem:windows /machine:x64
LINK : fatal error LNK1104: cannot open file 'QuantLib-vc90-x64-mt.lib'
error: command 'C:\\Users\\user1\\AppData\\Local\\Programs\\Common\\Microsoft\\Visual C++ for Python\\9.0\\VC\\Bin\\amd64\\link.exe' failed with exit status 1104
C:\QuantLib-SWIG-1.12\Python>
python setup.py build worked under Python 3.6.5.

MSVC2017 compiler error, Chromium build fails

So I am on:
Windows 10
MS Visual Studio 2017 (2017 build tools)
trying to build:
qt5.10.1 with QtWebEngine
using jom.exe -j4
and during the QtWebEngine build process, this happened:
[51/12427] CC obj/third_party/webrtc/common_audio/common_audio_c/sqrt_of_one_minus_x_squared.obj
[52/12427] CC obj/third_party/webrtc/common_audio/common_audio_c/complex_fft.obj
[53/12427] CXX obj/third_party/webrtc/call/call/call.obj
FAILED: obj/third_party/webrtc/call/call/call.obj
ninja -t msvc -e environment.x64 -- "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.14.26428\bin\HostX64\x64/cl.exe" /nologo /showIncludes #obj/third_party/webrtc/call/call/call.obj.rsp /c ../../3rdparty/chromium/third_party/webrtc/call/call.cc /Foobj/third_party/webrtc/call/call/call.obj /Fd"obj/third_party/webrtc/call/call_cc.pdb"
C:\Qt\qt-everywhere-src-5.10.1\qtwebengine\src\3rdparty\chromium\third_party\webrtc/modules/video_coding/sequence_number_util.h(101): fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'f:\dd\vctools\compiler\cxxfe\sl\p1\c\outdname.c', line 5310)
To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.14.26428\include\xutility(301): note: see reference to class template instantiation 'webrtc::DescendingSeqNumComp<uint16_t,0>' being compiled
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.14.26428\include\xutility(301): note: see reference to variable template 'const bool is_empty_v<webrtc::DescendingSeqNumComp<unsigned short,0> >' being compiled
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.14.26428\include\xtree(1078): note: see reference to class template instantiation 'std::_Tree_comp_alloc<_Traits>' being compiled
with
[
_Traits=std::_Tmap_traits<uint16_t,webrtc::NackModule::NackInfo,webrtc::DescendingSeqNumComp<uint16_t,0>,std::allocator<std::pair<const uint16_t,webrtc::NackModule::NackInfo>>,false>
]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.14.26428\include\map(82): note: see reference to class template instantiation 'std::_Tree<std::_Tmap_traits<_Kty,_Ty,_Pr,_Alloc,false>>' being compiled
with
[
_Kty=uint16_t,
_Ty=webrtc::NackModule::NackInfo,
_Pr=webrtc::DescendingSeqNumComp<uint16_t,0>,
_Alloc=std::allocator<std::pair<const uint16_t,webrtc::NackModule::NackInfo>>
]
C:\Qt\qt-everywhere-src-5.10.1\qtwebengine\src\3rdparty\chromium\third_party\webrtc/modules/video_coding/nack_module.h(88): note: see reference to class template instantiation 'std::map<uint16_t,webrtc::NackModule::NackInfo,webrtc::DescendingSeqNumComp<uint16_t,0>,std::allocator<std::pair<const _Kty,_Ty>>>' being compiled
with
[
_Kty=uint16_t,
_Ty=webrtc::NackModule::NackInfo
]
[54/12427] CC obj/third_party/webrtc/common_audio/common_audio_c/refl_coef_to_lpc.obj
[55/12427] CC obj/third_party/webrtc/common_audio/common_audio_c/vector_scaling_operations.obj
[56/12427] CC obj/third_party/webrtc/common_audio/common_audio_c/spl_sqrt_floor.obj
[57/12427] CC obj/third_party/webrtc/common_audio/common_audio_c/resample_by_2.obj
[58/12427] CC obj/third_party/webrtc/common_audio/common_audio_c/webrtc_vad.obj
[59/12427] CC obj/third_party/webrtc/common_audio/common_audio_c/spl_init.obj
[60/12427] CXX obj/third_party/webrtc/common_audio/common_audio/sparse_fir_filter.obj
[61/12427] CXX obj/third_party/webrtc/common_audio/common_audio/real_fourier_ooura.obj
[62/12427] CXX obj/third_party/webrtc/common_audio/common_audio_cc/dot_product_with_scale.obj
ninja: build stopped: subcommand failed.
jom: C:\Qt\qt-everywhere-src-5.10.1\qtwebengine\src\core\Makefile.gn_run.Debug [run_ninja] Error 1
jom: C:\Qt\qt-everywhere-src-5.10.1\qtwebengine\src\core\Makefile.gn_run [debug-all] Error 2
jom: C:\Qt\qt-everywhere-src-5.10.1\qtwebengine\src\core\Makefile [sub-gn_run-pro-make_first] Error 2
jom: C:\Qt\qt-everywhere-src-5.10.1\qtwebengine\src\Makefile [sub-core-make_first] Error 2
jom: C:\Qt\qt-everywhere-src-5.10.1\qtwebengine\Makefile [sub-src-make_first] Error 2
jom: C:\Qt\qt-everywhere-src-5.10.1\Makefile [module-qtwebengine-make_first] Error 2
C:\Qt\qt-everywhere-src-5.10.1>
I found this forum with a slightly active/recent question asking about this same issue here:
Internal compiler error in outdname.c in VS15.7p3 when building Firefox webrtc code
Is there anything I can do from this point to fix this?
Downgrading my version of VS to 2015 allowed me to bypass this compiler error and compile QT successfully.

How to set compiler options with CMake in Visual Studio 2017

Visual Studio 2017 comes with full CMake integration. To learn about this combination, I was starting with this basic sample:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.8)
project(foo)
add_executable(foo foo.cpp)
and
// foo.cpp
int main() {}
This properly generates build scripts, and compiles and links with no issues. That was easy.
Trying to set compiler options, on the other hand, turned out to be anything but trivial. In my case I was attempting to set the warning level to 4.
The obvious solution
add_compile_options("/W4")
didn't pan out as expected. The command line passed to the compiler now contains both /W4 (as intended) as well as /W3 (picked up from somewhere else), producing the following warning:
cl : Command line warning D9025: overriding '/W3' with '/W4'
To work around this, I would need to replace any incompatible compiler option(s) instead of just adding one. CMake does not provide any immediate support for this, and the standard solution (as this Q&A suggests) seems to be:
if(CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
string(REGEX REPLACE "/W[0-4]" "/W4" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
else()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
endif()
This, however, has two issues:
It sets the global CMAKE_CXX_FLAGS, applying to all C++ targets. This may not be intended (not an issue for me right now).
It doesn't scale. For every compiler option to add, you would have to read up on incompatible options, and manually strip those first. This will inevitably fail1.
My question is two-fold:
Where does the CMake integration pick up default settings from, and can this be controlled?
How do you set compiler options in general? (If this is too broad a topic, I'd be happy for help on setting the warning level only.)
1 Incidentally, the solution I replicated fails to account for the /Wall option, that is incompatible with /W4 as well.
The default settings for the compiler are picked up from standard module files located in the Modules directory of the CMake installation. The actual module file used depends on both the platform and the compiler. E.g., for Visual Studio 2017, CMake will load the default settings from the file Windows-MSVC.cmake and language specific settings from Windows-MSVC-C.cmake or Windows-MSVC-CXX.cmake.
To inspect the default settings, create a file CompilerOptions.cmake in the project directory with the following contents:
# log all *_INIT variables
get_cmake_property(_varNames VARIABLES)
list (REMOVE_DUPLICATES _varNames)
list (SORT _varNames)
foreach (_varName ${_varNames})
if (_varName MATCHES "_INIT$")
message(STATUS "${_varName}=${${_varName}}")
endif()
endforeach()
Then initialize the CMAKE_USER_MAKE_RULES_OVERRIDE variable in your CMakeLists.txt:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.8)
set (CMAKE_USER_MAKE_RULES_OVERRIDE "${CMAKE_CURRENT_LIST_DIR}/CompilerOptions.cmake")
project(foo)
add_executable(foo foo.cpp)
When the project is configured upon opening the directory using Open Folder in Visual Studio 2017, the following information will be shown in the IDE's output window:
...
-- CMAKE_CXX_FLAGS_DEBUG_INIT= /MDd /Zi /Ob0 /Od /RTC1
-- CMAKE_CXX_FLAGS_INIT= /DWIN32 /D_WINDOWS /W3 /GR /EHsc
-- CMAKE_CXX_FLAGS_MINSIZEREL_INIT= /MD /O1 /Ob1 /DNDEBUG
-- CMAKE_CXX_FLAGS_RELEASE_INIT= /MD /O2 /Ob2 /DNDEBUG
-- CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT= /MD /Zi /O2 /Ob1 /DNDEBUG
...
So the warning setting /W3 is picked up from the CMake variable CMAKE_CXX_FLAGS_INIT which then applies to all CMake targets generated in the project.
To control the warning level on the CMake project or target level, one can alter the CMAKE_CXX_FLAGS_INIT variable in the CompilerOptions.cmake by adding the following lines to the file:
if (MSVC)
# remove default warning level from CMAKE_CXX_FLAGS_INIT
string (REGEX REPLACE "/W[0-4]" "" CMAKE_CXX_FLAGS_INIT "${CMAKE_CXX_FLAGS_INIT}")
endif()
The warning flags can then be controlled by setting the target compile options in CMakeLists.txt:
...
add_executable(foo foo.cpp)
target_compile_options(foo PRIVATE "/W4")
For most CMake projects it makes sense to control the default compiler options in a rules override file instead of manually tweaking variables like CMAKE_CXX_FLAGS.
When making changes to the CompilerOptions.cmake file, it is necessary to recreate the build folder. When using Visual Studio 2017 in Open Folder mode, choose the command Cache ... -> Delete Cache Folders from the CMake menu and then Cache ... -> Generate from the CMake menu to recreate the build folder.
Turning my comment into an answer
CMake does come with some compiler switches preset. For visual studio those are mainly standard link libraries, warning levels, optimization levels, exception handling, debug information and platform specific defines.
What you now have to differentiate when you want to change a CMake generated compiler settings are the following use cases:
Additional compiler flags CMake does not define vs. changing CMake's preset settings
Project default settings vs. project user defined settings
So let's discuss common solutions for those cases.
User changes/adds to Project/CMake Compiler Flags Defaults
The standard way would be to modify the cached compiler flags variables by using tools shipped with CMake like cmake-gui and ccmake.
To achieve this in Visual Studio you would have to:
CMake / Cache / View CMakeCache
Manually change e.g. CMAKE_CXX_FLAGS to /Wall
CMakeCache.txt
//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING= /DWIN32 /D_WINDOWS /Wall /GR /EHsc
CMake / Cache / Generate
Or you preset the CMAKE_CXX_FLAGS cache variable via a CMakeSettings.json file:
CMake / Change CMake Settings
Force the cache entry with -DCMAKE_CXX_FLAGS:STRING=... in cmakeCommandArgs
CMakeSettings.json
{
// See https://go.microsoft.com//fwlink//?linkid=834763 for more information about this file.
"configurations": [
{
"name": "x86-Debug (all warnings)",
"generator": "Visual Studio 15 2017",
"configurationType": "Debug",
"buildRoot": "${env.LOCALAPPDATA}\\CMakeBuild\\${workspaceHash}\\build\\${name}",
"cmakeCommandArgs": "-DCMAKE_CXX_FLAGS:STRING=\"/DWIN32 /D_WINDOWS /Wall /GR /EHsc\"",
"buildCommandArgs": "-m -v:minimal"
}
]
}
If you deliver this CMakeSettings.json file with your CMake project it gets permanent
Project changes to CMake Compiler Flags Defaults
If you want to keep most of CMake's compiler flags in place, #sakra's answer is definitely the way to go.
For my VS projects I've put the CXX flag settings into a toolchain file coming with the project itself. Mainly to freeze those settings and don't have a dependency the CMake version used or any environment variables set.
Taking the example from above that would look like:
VS2017Toolchain.cmake
set(CMAKE_CXX_FLAGS "/DWIN32 /D_WINDOWS /Wall /GR /EHsc" CACHE INTERNAL "")
CMakeSettings.json
{
// See https://go.microsoft.com//fwlink//?linkid=834763 for more information about this file.
"configurations": [
{
"name": "x86-Debug (all warnings)",
"generator": "Visual Studio 15 2017",
"configurationType": "Debug",
"buildRoot": "${env.LOCALAPPDATA}\\CMakeBuild\\${workspaceHash}\\build\\${name}",
"cmakeCommandArgs": "-DCMAKE_TOOLCHAIN_FILE:FILEPATH=\"${projectDir}\\VS2017Toolchain.cmake\"",
"buildCommandArgs": "-m -v:minimal"
}
]
}
References
Visual C++ Team Blog: CMake support in Visual Studio – the Visual Studio 2017 RC update
set diagnostics:caret from CMakeLists.txt
Is Cmake set variable recursive?
Passing compiler options cmake
In CMake 3.15, CMake introduced a fix for this MSVC-specific warning:
cl : Command line warning D9025: overriding '/W3' with '/W4'
and the compiler warning flags (like /W3) are no longer automatically added. So by upgrading to CMake 3.15 or greater, this warning should no longer appear. From the docs:
When using MSVC-like compilers in CMake 3.14 and below, warning flags like /W3 are added to CMAKE_<LANG>_FLAGS by default. This is problematic for projects that want to choose a different warning level programmatically. In particular, it requires string editing of the CMAKE_<LANG>_FLAGS variables with knowledge of the CMake builtin defaults so they can be replaced.
CMake 3.15 and above prefer to leave out warning flags from the value of CMAKE_<LANG>_FLAGS by default.
Along with this fix, CMake introduced policy CMP0092, which allows you to switch back to the OLD behavior (adding the warning flags by default) if necessary.

"Compiling Desktop applications for the ARM platform is not supported" when building OpenSSL

I am trying to build OpenSSL from source (branch OpenSSL_1_0_1-stable) using Visual C++ (Visual Studio 2015 is installed) by following the instructions here.
When I run nmake -f ms\ntdll.mak I get the following output:
Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation. All rights reserved.
Building OpenSSL
perl util/copy.pl ".\crypto\buildinf.h" "tmp32dll\buildinf.h"
Copying: ./crypto/buildinf.h to tmp32dll/buildinf.h
perl util/copy.pl ".\crypto\opensslconf.h" "inc32\openssl\opensslconf.h"
Copying: ./crypto/opensslconf.h to inc32/openssl/opensslconf.h
cl /Fotmp32dll\uplink.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_CIPHERS -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -c ms\uplink.c
uplink.c
C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\corecrt.h(205): fatal error C1189: #error: Compiling Desktop applications for the ARM platform is not supported.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_arm\cl.EXE"' : return code '0x2'
Stop.
My ms/ntdll.mak file content:
# This makefile has been automatically generated from the OpenSSL distribution.
# This single makefile will build the complete OpenSSL distribution and
# by default leave the 'interesting' output files in .\out and the stuff
# that needs deleting in .\tmp.
# The file was generated by running 'make makefile.one', which
# does a 'make files', which writes all the environment variables from all
# the makefiles to the file call MINFO. This file is used by
# util\mk1mf.pl to generate makefile.one.
# The 'makefile per directory' system suites me when developing this
# library and also so I can 'distribute' indervidual library sections.
# The one monster makefile better suits building in non-unix
# environments.
INSTALLTOP=D:\TelegramDesktop\Libraries\openssl\Release
OPENSSLDIR=D:\TelegramDesktop\Libraries\openssl\Release\ssl
# Set your compiler options
PLATFORM=VC-WIN32
CC=cl
CFLAG= /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_CIPHERS -DOPENSSL_NO_STATIC_ENGINE
APP_CFLAG= /Zi /Fd$(TMP_D)/app
LIB_CFLAG= /Zi /Fd$(TMP_D)/lib -D_WINDLL
SHLIB_CFLAG=
APP_EX_OBJ=setargv.obj $(OBJ_D)\applink.obj /implib:$(TMP_D)\junk.lib
SHLIB_EX_OBJ=
# add extra libraries to this define, for solaris -lsocket -lnsl would
# be added
EX_LIBS=ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib
# The OpenSSL directory
SRC_D=.
LINK_CMD=link
LFLAGS=/nologo /subsystem:console /opt:ref /debug
RSC=rc
# The output directory for everything intersting
OUT_D=out32dll
# The output directory for all the temporary muck
TMP_D=tmp32dll
# The output directory for the header files
INC_D=inc32
INCO_D=inc32\openssl
PERL=perl
CP=$(PERL) util/copy.pl
RM=del /Q
RANLIB=
MKDIR=$(PERL) util/mkdir-p.pl
MKLIB=lib /nologo
MLFLAGS= /nologo /subsystem:console /opt:ref /debug /dll
ASM=ml /nologo /Cp /coff /c /Cx /Zi
# FIPS validated module and support file locations
FIPSDIR=\usr\local\ssl\fips-2.0
BASEADDR=0xFB00000
FIPSLIB_D=$(FIPSDIR)\lib
FIPS_PREMAIN_SRC=$(FIPSLIB_D)\fips_premain.c
O_FIPSCANISTER=$(FIPSLIB_D)\fipscanister.lib
FIPS_SHA1_EXE=$(FIPSDIR)\bin\fips_standalone_sha1.exe
E_PREMAIN_DSO=fips_premain_dso
PREMAIN_DSO_EXE=$(BIN_D)\fips_premain_dso.exe
FIPSLINK=$(PERL) $(FIPSDIR)\bin\fipslink.pl
Running nmake -f ms\nt.mak produces the same error.
I am not sure why building for platform VC-WIN32 leads to an error about ARM platform. Also, I haven't find any question about this error on VS2015, only VS2013 and below, in which compiling for ARM platform is really not supported.
Any suggestions?
I've found out what was wrong:
I have run the commands in VS2015 x64 ARM Cross Tools Command Prompt instead of in VS2015 x86 Native Cross Tools Command Prompt.
Running in VS2015 x86 Native Cross Tools Command Prompt solved the issue.

Resources