There are many posts about how to set the Runtime library in Visual Studio from CMake, but in my case it seems that Visual Studio is ignoring my setting.
I would like to build google-mock with /MD. This is the default setting in the project.
In a fresh build directory, built with:
cmake -G "Visual Studio 12 2013" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=C:\Users\mrussell\workspace\opal2\o2win32\Libs\gtest\"1.7.0" -DCMAKE_CXX_FLAGS_RELEASE="/MD /O2 /Ob2 /D NDEBUG" ../googlemock
All my cmake variables seem correct
However, when I go to build, either via the command line (I'm used to linux..) or from Visual Studio, it uses the /MT flag.
My build command (targeting 32 bit):
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\vcvars32.bat"
msbuild /m:4 /property:Configuration=%build_type% ALL_BUILD.vcxproj
Output:
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\CL.exe /c /IC:\Users\mrussell\workspace\opal2\o2win32\Libs\gtest\g
test\include /IC:\Users\mrussell\workspace\opal2\o2win32\Libs\gtest\gtest /Zi /nologo /W4 /WX /O2 /Ob2 /Oy- /D WIN32 /D _WIND
OWS /D NDEBUG /D WIN32 /D _WINDOWS /D _UNICODE /D UNICODE /D WIN32 /D _WIN32 /D STRICT /D WIN32_LEAN_AND_MEAN /D GTEST_HAS_PT
HREAD=0 /D _HAS_EXCEPTIONS=1 /D "CMAKE_INTDIR=\"Release\"" /D _UNICODE /D UNICODE /Gm- /EHsc /MT /GS /fp:precise /Zc:wchar_t
/Zc:forScope /GR /Fo"gtest.dir\Release\\" /Fd"gtest.dir\Release\vc120.pdb" /Gd /TP /wd4127 /wd4251 /wd4275 /analyze- /errorRe
port:queue -J "C:\Users\mrussell\workspace\opal2\o2win32\Libs\gtest\gtest\src\gtest-all.cc"
(note the /MT hiding in there.)
In Visual Studio, I open the solution, choose release type Release, and in any of the targets, say gtest, Properties -> Configuration Properties -> C/C++ -> Code Generation, the Runtime Library is set to /MT, not /MD as set in the Cmake file.
Same thing happens if I try to build google-test (1.7.0)
Do I just not understand how to set these? Or is there a way to force Visual Studio to use the right flag without manually opening Visual Studio and setting it?
The CMake build systems of both google-test and google-mock aren't well behaved. They do not obey the compile options and runtime option set up by the user for good reason and override those with options that they consider reasonable for testing purposes.
To prevent the replacement of MD with MT you can set the option gtest_force_shared_crt to ON in the CMake cache. The modification of other compile options (e.g., warnings) however is done unconditionally.
Related
I'm trying to configure CMake 3.24.2 to generate a Visual Studio 2019 project that uses ccache to cache the output of previous builds. For that, I'm following alternative #1 from ccache's docs, where I'm trying to configure CMake to point the compiler to a copy of ccache which I've dumped in C:/tools/ccache/cl.exe. For that purpose I'm setting CMAKE_CXX_COMPILER to point to my ccache.exe, and I'm generating the project with the following command.
cmake.exe -DCMAKE_CXX_COMPILER=C:/tools/ccache/cl.exe -G "Visual Studio 16 2019" -A Win32 -DCMAKE_INSTALL_LIBDIR=lib/win/Release/x86 -S D:\proj\testproject -B D:\proj\testproject\cmake-build-release
However, this does not work and the vs2019 project keeps on pointing to the original cl.exe command. Here's an except I've taken from D:\proj\testproject\cmake-build-release\CMakeFiles\CMakeOutput.log:
The system is: Windows - 10.0.19041.0 - AMD64
Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" succeeded.
Compiler: C:/tools/ccache/cl.exe
Build flags:
Id flags:
The output was:
0
Microsoft (R) Build Engine version 16.11.2+f32259642 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 2/11/2023 4:51:26 PM.
Project "D:\proj\testproject\cmake-build-release\CMakeFiles\3.24.2\CompilerIdCXX\CompilerIdCXX.vcxproj" on node 1 (default targets).
PrepareForBuild:
Creating directory "Debug\".
Creating directory "Debug\CompilerIdCXX.tlog\".
InitializeBuildStatus:
Creating "Debug\CompilerIdCXX.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30133\bin\HostX64\x86\CL.exe /c /nologo /W0 /WX- /diagnostics:column /Od /Oy- /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\\" /Fd"Debug\vc142.pdb" /external:W0 /Gd /TP /analyze- /FC /errorReport:queue CMakeCXXCompilerId.cpp
CMakeCXXCompilerId.cpp
(...)
Apparently the Visual Studio 2019 project does get the hint that it should use C:/tools/ccache/cl.exe, but for some unknown reason its ClCompile entry points to the original cl.exe.
Does anyone know what's going on for the Visual Studio 2019 insisting on not using the C++ compiler passed with CMAKE_CXX_COMPILER?
This happens because the original cl.exe is inferred from the chosen generator "Visual Studio 16 2019".
In order to switch to another compiler you should use other generator e.g. Ninja or Unix Makefiles.
I work on the CMake-based Qt project in MS Visual Studio. When I try to evaluate any method of a Qt object, I receive the error:
Function <blablabla> has no address, possibly due to compiler optimizations.
Image: QuickWatch evaluation error
I build in the DEBUG mode; I see the compiler invoked with no optimizations:
cl.exe ... /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MDd /Zi /Ob0 /Od /RTC1
Also, I checked the PDBs are loaded:
Image: VS Modules Window with PDBs loaded
But nothing of this helps: all the objects evaluated well, but Qt's - are not.
Is there anything that will make the Visual Studio evaluate Qt objects' properties?
My problem is similar to this one: Problems generating solution for VS 2017 with CMake, but the solution doesn't work for me.
When run cmake in Developer Command Prompt for VS 2017, I got the error (from CMakeError.log):
LINK : fatal error LNK1104: Cannot open file "ucrtd.lib" [E:\Projects\My Project\VS\CMakeFiles\3.14.4\CompilerIdC\CompilerIdC.vcxproj]
But the file ucrtd.lib is located in the Windows Kits folder.
echo %LIB%
D:\Program Files (x86)\Microsoft Visual Studio 2017 Community\VC\Tools\MSVC\14.16.27023\lib\x86;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x86;C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\ucrt\x86;C:\Program Files(x86)\Windows Kits\10\lib\10.0.17763.0\um\x86;
dir "C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\ucrt\x86\" /w /b
libucrt.lib
libucrtd.lib
ucrt.lib
ucrtd.lib
And I also try to manually run the build command listed in the CMakeError.log, it succeeds, no error.
CL.exe /c /nologo /W0 /WX- /diagnostics:classic /Od /Oy- /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\" /Fd"Debug\vc141.pdb" /Gd /TC /analyze- /FC /errorReport:queue CMakeCCompilerId.c
link.exe /ERRORREPORT:QUEUE /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:".\CompilerIdC.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdC.lib" /MACHINE:X86 /SAFESEH Debug\CMakeCCompilerId.obj
So it seems like cmake didn't recognize the environment variables, or did I miss some important steps?
cmake version is 3.14.4
visual studio version is 15.9.7
tl;dr:
Make sure HKLM\Software\Microsoft\Windows Kits\Installed Roots#KitsRoot10 is set to:
C:\Program Files (x86)\Windows Kits\10\
and NOT:
C:\Program Files\Windows Kits\10\
Full Explanation
On the LNK1104 error page, there's a relevant section titled, "Updated Windows SDK libraries", that reads:
This error can occur when the Visual Studio path to the Windows SDK is
out of date. It may happen if you install a newer Windows SDK
independently of the Visual Studio installer. To fix it in the IDE,
update the paths specified in the VC++ Directories property page.
Set the version in the path to match the new SDK. If you use the
Developer Command Prompt, update the batch file that initializes the
environment variables with the new SDK paths. This problem can be
avoided by using the Visual Studio installer to install updated SDKs.
Given this, the reasonable thing to do would seem to be to verify that the "Macro" pointing to the path containing the ucrt library files is in use.
However, this may not be enough. That Macro may be wrong.
This message from a Microsoft engineer says that some older Windows Kits improperly set the path to the ucrt. In these kits, they use the 64-bit program files path ("Program Files") instead of the 32-bit path ("Program Files (x86)"). However, during installation, if the path is already set, then it will not be updated by a subsequent Windows SDK installer.
So it's possible that your system will have the environment variable defined to the wrong value, resulting in Visual Studio failing to find the relevant library.
In that case, the Microsoft engineer's recommendation was to either update the offending registry value, or delete it then reinstall the Windows SDK.
Hey Alexander,
I've spoken to the Windows SDK team about this. In general, kit
installers are not supposed to set 'HKLM\Software\Microsoft\Windows
Kits\Installed Roots#KitsRoot10' to C:\Program Files\Windows Kits\10,
it is always supposed to point to C:\Program Files (x86)\Windows
Kits\10. However, there are Kits out there that make this mistake, and
the registry key is never updated if it already exists prior to any
kit installation. I believe whichever windows kit you've installed on
that system first had this issue.
That said, these issues will never go away entirely since there will
always be kits and machines floating around with this issue. I've
updated ucrt.props to be more defensive about this by checking the
Wow6432Node version first (which has not had this issue historically),
and only if that isn't present to fall back to the usual registry key.
This fix will be present in the next released Windows 10 SDK. In the
meantime, I recommend either deleting that reg key and reinstalling
the Windows 10 SDK, or simply directly modifying
HKLM\Software\Microsoft\Windows Kits\Installed Roots#KitsRoot10 to
point to C:\Program Files (x86)\Windows Kits\10 (the same effects of
the deleting the reg key and reinstalling, but less error prone).
Hope this helps!
Steve Wishnousky Senior Software Engineer - Visual C++ Libraries
stwish#microsoft.com
(quoted here because of concerns about the long-term availability of the message at the link)
As described here, if you're on VS2022 and your installed Windows SDK is version 10.0.19041.0 (which is what installs with VS2022 as the default as of this writing), then you may have run into this.
The solution in that case is to uninstall that SDK version and install a different one.
As mentioned in this CMake forum, it may be necessary to explicitly tell CMake which specific Windows version you have installed. Considering you have version 10.0.17763.0 installed, including the following definition will direct CMake to that version:
cmake -DCMAKE_SYSTEM_VERSION=10.0.17763.0
Here are the docs for CMAKE_SYSTEM_VERSION.
I use Intel C++ Compiler v. 13 for OS Windows in MS Visual Studio 2010. This compiler support vectorize a code. I want to disable this option, but save enabled -O2 optimization. I set for this goal /Qvec- flag in Project -> Properties -> Configuration Properties -> C/C++ -> Command Line -> Additional Options window (label "Inherit from parent or project defaults" is enabled). In All options section shown these keys:
/Zi /nologo /W3 /Od /Ot /Qipo /Qopt-matmul /D "WIN32" /D "NDEBUG" /D
"_CONSOLE" /D "NOALIAS" /D "_UNICODE" /D "UNICODE" /EHsc /MT /GS /Gy
/fp:fast /QaxAVX /Zc:wchar_t /Zc:forScope /Qopenmp /Qstd=c99
/Qstd=c++11 /Fp"Release\mformat.pch" /Fa"Release\" /Fo"Release\"
/Fd"Release\vc100.pdb" /Qvec-report2 /Gd
But in compilation report output this messages:
service.cpp(164): warning : SIMD LOOP WAS VECTORIZED.
service.cpp(535): warning : SIMD LOOP WAS VECTORIZED.
service.cpp(543): warning : loop was not vectorized: nonstandard loop
is not a vectorization candidate.
etc...
And program time is not change. How i can disable vectorization and no set \Od key?
Found this in the document "A Guide to Vectorization with Intel® C++ Compilers"
To allow comparisons of vectorized with unvectorized code,
vectorization may be disabled with the switch /Qvec- (Windows*) or
-no-vec (Linux* or Mac OS* X).
Lots of additional good information on the Intel® Composer XE Suite page.
I have a project which uses PoDoFo for PDF support and I am trying to update it to use the HEAD version from the SVN tree.
The big change from the last version I used is the addition on libcrypto from OpenSSL, which seems to be required. I downloaded and built OpenSSL and set up the appropriate options (or so I had hoped) so that cmake could find libcrypto.
cmake seems to find it ok, but when I try to build from the resulting makefile, I get the error:
Encrypt.cpp(50) : fatal error C1083: Cannot open include file: 'openssl/md5.h': No such file or directory
I whittled down my build script so that I could focus on this problem:
setlocal
set ROOT=%CD%
pushd podofo
set CMAKE_PARAMS=-Wno-dev -C ..\BuildSetup.cmake . -DCMAKE_INSTALL_PREFIX:PATH=%1
set CMAKE_PARAMS_RELEASE=-DCMAKE_BUILD_TYPE=Release %CMAKE_PARAMS%
call "%VS100COMNTOOLS%..\..\vc\vcvarsall.bat" x86
del CMakeCache.txt >nul
rd /s /q CMakeFiles >nul
set CMAKE_PREFIX_PATH=%ROOT%\install\zlib\x86
set CMAKE_PREFIX_PATH=%CMAKE_PREFIX_PATH%;%ROOT%\install\freetype\x86
set CMAKE_PREFIX_PATH=%CMAKE_PREFIX_PATH%;%ROOT%\install\libjpeg\x86
set CMAKE_PREFIX_PATH=%CMAKE_PREFIX_PATH%;%ROOT%\install\libpng\x86
set CMAKE_PREFIX_PATH=%CMAKE_PREFIX_PATH%;%ROOT%\install\openssl\x86
set CRYPTO=-DLIBCRYPTO_INCLUDE_DIR=%ROOT%\install\openssl\x86\include
set CRYPTO=%CRYPTO% -DLIBCRYPTO_LIBRARY_NAMES=libeay32
cmake %CRYPTO% %CMAKE_PARAMS_RELEASE%\x86 -G "NMake Makefiles"
cmake --build . --target install --clean-first
popd
endlocal
My BuildSetup.cmake file:
set (CMAKE_CONFIGURATION_TYPES "Debug;Release" CACHE STRING "config types" FORCE)
set (CMAKE_INSTALL_PREFIX "../install" CACHE PATH "install path" FORCE)
set (CMAKE_C_FLAGS_RELEASE "/MT /O1 /Ob2 /D NDEBUG" CACHE STRING "C release flags" FORCE)
set (CMAKE_CXX_FLAGS_RELEASE "/MT /O1 /Ob2 /D NDEBUG" CACHE STRING "C++ release flags" FORCE)
set (CMAKE_C_FLAGS_DEBUG "/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1" CACHE STRING "C debug flags" FORCE)
set (CMAKE_CXX_FLAGS_DEBUG "/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1" CACHE STRING "C++ debug flags" FORCE)
set (BUILD_SHARED_LIBS OFF CACHE STRING "")
I tried explicitly adding the path of openssl/md5.h to the INCLUDE environment variable with no effect.
I also tried using the "Visual Studio 10" generator. Same problem.
i just run into the same issue!
If you are building with VisualStudio, you have to add the openssl directory manually to the c++ include directories in the project properties of podofo.
in my case ..\openssl_vc10\include
then the build is successfull.
dont have time atm to check why cmake dont set this.
StefanB's answer is correct. I needed to add the include path to get cmake to correctly build it. However, instead of manually hacking the project file (or makefile in my case), I used the CL environment variable to tell the compiler where to look for the OpenSSL headers. I added the command:
set CL=/I "%ROOT%\install\openssl\x86\include"
before running cmake and it built without errors.