Configuring protobuf C++ to dynamically link against MSVC runtime library - c++

I would like to configure protobuf to link MSVC runtime library dynamically. While this is supported by protobuf and seems trivial to do, I have not been able to do that.
Here's my CMake command (through bat file, execute from protobuf's source code root directory)
setlocal
#call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build\vcvars64.bat"
cd cmake
mkdir build & cd build
cmake -G "Visual Studio 16 2019" -DCMAKE_INSTALL_PREFIX=../../install -Dprotobuf_BUILD_SHARED_LIBS=OFF -Dprotobuf_MSVC_STATIC_RUNTIME=OFF -Dprotobuf_BUILD_TESTS=OFF ..
if %ERRORLEVEL% NEQ 0 EXIT /B 1
cmake --build . --config Release
if %ERRORLEVEL% NEQ 0 EXIT /B 1
cmake --install .
if %ERRORLEVEL% NEQ 0 EXIT /B 1
cd ../..
mkdir dist
tar -C install -czf dist/protobuf.tar.gz .
if %ERRORLEVEL% NEQ 0 EXIT /B 1
However, whenever I checked with dumpbin, this is what I got:
dumpbin /nologo /directives libprotobuf.lib
Dump of file libprotobuf.lib
File Type: LIBRARY
Linker Directives
-----------------
/FAILIFMISMATCH:_CRT_STDIO_ISO_WIDE_SPECIFIERS=0
/FAILIFMISMATCH:_MSC_VER=1900
/FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=0
/FAILIFMISMATCH:RuntimeLibrary=MT_StaticRelease
/DEFAULTLIB:libcpmt
/DEFAULTLIB:LIBCMT
/DEFAULTLIB:OLDNAMES
Based on /FAILIFMISMATCH:RuntimeLibrary=MT_StaticRelease , I assume this is still linking statically against MSVC? If yes, how should I configure my CMake command in order to achieve what I want?

To linkt MSVC runtime dynamically, you are looking for protobuf_MSVC_STATIC_RUNTIME=OFF
Building ProtoBuf this way fixes errors like libprotobuf.lib(common.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' for default CMake settings in Visual Studio.

Related

'base/debug/debugging_buildflags.h' file not found when building project with webrtc

I am building a project that includes webrtc with CMake, Visual Studio 2019 and ClangCl. This is the command I run to configure :
cmake -G "Visual Studio 16 2019" -A Win32 -DCMAKE_BUILD_TYPE=Debug -DDEPOT_TOOLS_PATH="C:\dev\depot_tools" -T ClangCl -S . -B debug-x86
and to build :
cmake --build debug-x86 --parallel --config Debug --target
The cmake script runs this command at config:
gn.bat gen /path/to/project/debug-x86/vendor/webrtc/Debug --args= use_gold=false target_cpu="x86" target_os="win" rtc_build_examples=false rtc_initialize_ffmpeg=false rtc_build_tools=false rtc_use_h264=false is_component_build=false rtc_enable_protobuf=false clang_use_chrome_plugins=false use_custom_libcxx_for_host=false treat_warnings_as_errors=false use_sysroot=false enable_location_source=false is_official_build=false use_rtti=true use_custom_libcxx=false rtc_include_tests=false is_debug=true symbol_level=2 enable_iterator_debugging=true
and runs this command at build before building the main project:
C:/Dev/depot_tools/ninja.exe -C path/to/project/debug-x86/vendor/webrtc/Debug webrtc system_wrappers builtin_audio_decoder_factory libjingle_peerconnection
My problem is that when building the main project i receive this error :
vendor\webrtc\src\base/dcheck_is_on.h(8,10): fatal error : 'base/debug/debugging_buildflags.h' file not found
My understanding is that this file is supposed to be generated by webertc/src/base/BUILD.gn. Am I missing an argument to trigger the generation? Why is this header not being generated? Thank you.

C3861 - 'SSL_set_tlsext_host_name': identifieer not found building rest-cpp for windows 10

I'm trying to build rest-cpp lib for windows but it is failing with this error when I run the build script, I find it strange that Visual Studio 2019 can find a reference for this symbol inside a header referenced before but it still fails building.
I've only changed the .bat file in order to build in my machie:
rem Example file on how to build under Windows
rem using DCMAKE_PREFIX_PATH to specify where
rem cmake's find* should look for dependencies.
rmdir /S /Q build
mkdir build
cd build
rem -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
cmake -DCMAKE_PREFIX_PATH=C:\libraries_CPP\include;C:\libraries_CPP\include\openssl;C:\libraries_CPP\include\boost;C:\libraries_CPP\lib\x64;C:\libraries_CPP\bin\x64; -G "Visual Studio 16 2019" ..
cmake --build . --config Debug
cmake --build . --config Release
cd ..
#pause
This is the error message:
RestClientImpl.cpp
RequestImpl.cpp
ReplyImpl.cpp
ConnectionPoolImpl.cpp
C:\Users\fabiotk\Downloads\restc-cpp-0.10.0\src\TlsSocketImpl.h(74,13): error C3861:
'SSL_set_tlsext_host_name': identificador não encontrado [C:\Users\fabiotk\Downloads\restc-cpp-0.10.0\build\restc-cpp.vcxproj]
However the symbol is defined in C:\libraries_CPP\include\openssl\tls1.h
#define SSL_set_tlsext_host_name(s,name) \
SSL_ctrl(s,SSL_CTRL_SET_TLSEXT_HOSTNAME,TLSEXT_NAMETYPE_host_name,(char *)name)
My question is why the compiler can't find the symbol?

How do I link external libraries to msvc cl compiler

today I was trying to link my external SDL2 library to my project to compile with cl.exe, but my program cannot find SDL2.lib and SDL2main.lib and while I trying to include any files, compiler cannot see them. Here is my bat file:
#echo off
if not defined DevEnvDir (
call vcvarsall x64
)
REM call vcvarsall x64
set LIB_VCPKG="F:\Env\vcpkg\installed\x64-windows\lib"
set MLIB_VCPKG="F:\Env\vcpkg\installed\x64-windows\lib\manual-link"
set INC_VCPKG="F:\Env\vcpkg\installed\x64-windows\include"
set CommonCompileFlags=-MD -nologo -fp:fast -EHa -Od -WX- -W4 -Oi -GR- -Gm- -GS -wd4100 -FC -Z7 -I %INC_VCPKG%
set CommonLinkFlags=/SUBSYSTEM:CONSOLE /LIBPATH:%LIB_VCPKG% /VERBOSE:LIB
if not exist ..\build mkdir ..\build
pushd ..\build
cl ..\code\main.cpp SDL2.lib SDL2main.lib %CommonCompileFlags% /link %CommonLinkFlags%
popd
What should I do to resolve this problem?

VS2013 compiling and linking tcl/tk 8.6.4 as a shared library

This question is kind of related to my earlier question of compiling and linking ngspice.
ngspice depends on tcl/tk so I have to build it.
I managed to build tcl in release configuration but everything else is failing.
I created a batch based on the information given on this website.
#ECHO OFF
set "vcvars32_bat=C:\LegacyApp\Microsoft Visual Studio 12.0\VC\bin\vcvars32.bat"
REM SET VARIABLES
call "%vcvars32_bat%"
set "TCLDIR=..\..\tcl8.6.4"
echo Building tcl Release 32
cd tcl8.6.4\win\
nmake -f makefile.vc > ..\..\tcl_Release32.log 2>&1
cd ..\..\
echo Building tk Release 32
cd tk8.6.4\win\
nmake -f makefile.vc > ..\..\tk_Release32.log 2>&1
cd ..\..\
echo Building tcl Debug 32
cd tcl8.6.4\win\
nmake -f makefile.vc OPTS=symbols > ..\..\tcl_Debug32.log 2>&1
cd ..\..\
echo Building tk Debug 32
cd tk8.6.4\win\
nmake -f makefile.vc OPTS=symbols > ..\..\tk_Debug32.log 2>&1
cd ..\..\
pause
exit 0
I added a bunch of messages to the makefiles so I can see whats going on.
makefile.vc depends on rules.vc. Somehow a custom "make helper" is also involved.
Here is some partial output:
Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation. All rights reserved.
makefile.vc
rules.vc
vercl.x
===============================================================================
*** Compiler has 'Optimizations'
*** Compiler does not have 'Pentium 0x0f fix'
*** Linker does not have 'Win98 alignment problem'
*** Doing symbols
*** Intermediate directory will be '.\Debug_VC12\tcl_ThreadedDynamic'
*** Output directory will be '.\Debug_VC12'
*** Suffix for binaries will be 'tg'
*** Optional defines are '-DTCL_CFGVAL_ENCODING=\"cp1252\" -DSTDC_HEADERS -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1'
*** Compiler version 12. Target machine is IX86
*** Host architecture is AMD64
*** Compiler options '-W3 -DUNICODE -D_UNICODE -Ot -Oi -fp:strict -Gs -GS -GL -RTC1 -W3'
*** Link options '-ltcg'
cdebug = -Zi -WX -RTC1
ldebug = -debug -debugtype:cv
lflags = -nologo -machine:IX86 -ltcg -debug -debugtype:cv
dlllflags = -nologo -machine:IX86 -ltcg -debug -debugtype:cv -dll
conlflags = -nologo -machine:IX86 -ltcg -debug -debugtype:cv -subsystem:console
guilflags = -nologo -machine:IX86 -ltcg -debug -debugtype:cv -subsystem:windows
*** Dependency rules are not being used.
Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation. All rights reserved.
===============================================================================
*** Compiler has 'Optimizations'
*** Compiler does not have 'Pentium 0x0f fix'
*** Linker does not have 'Win98 alignment problem'
*** Doing symbols
*** Intermediate directory will be '.\Debug_VC12\itcl_ThreadedDynamic'
*** Output directory will be '.\Debug_VC12'
*** Suffix for binaries will be 'tg'
*** Optional defines are '-DTCL_CFGVAL_ENCODING=\"cp1252\" -DSTDC_HEADERS -DTCL_THREADS=1'
*** Compiler version 12. Target machine is IX86
*** Host architecture is AMD64
*** Compiler options ' -Ot -Oi -fp:strict -Gs -GS -GL -RTC1 -W3'
*** Link options '-ltcg'
link -nologo -machine:IX86 -ltcg -debug:full -debugtype:cv -subsystem:windows -dll -base:#D:\Include\CPP\TCLTK\tcl8.6.4\win\..\win\coffbase.txt,itcl -out:".\Debug_VC12\itcl40tg.dll" "D:\Include\CPP\TCLTK\tcl8.6.4\win\..\win\Debug_VC12\tclstub86.lib" #C:\Users\HIRSCH~1\AppData\Local\Temp\nm8789.tmp
LINK : fatal error LNK1117: syntax error in option 'debug:full'
NMAKE : fatal error U1077: '"C:\LegacyApp\Microsoft Visual Studio 12.0\VC\BIN\link.EXE"' : return code '0x45d'
Stop.
Note that nmake is called a second time with different options and I don't know why or from where.
Is there a known solution to the issues that I am experiencing?
EDIT:
I am still on it. 'nmakehlp.exe' seems harmless. I edited a tracelog into it and the tool uses system calls to identify if compiler or linker options are valid. If I use it to see if the linker option '-debug:full' is valid it correctly identifies the error. I still am clueless when it comes to the additional calls to nmake. a textsearch on all files did not reveal where '-debug:full' or its fragments come from.
Version 8.5.18 does not have that issue so I just build that now instead of 8.6.4.
I use this batch to help with building.
#echo off
set "vcvars32_bat=D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\vcvars32.bat"
set "VERSION=8.5.18"
set "TCL=tcl%VERSION%"
set "TK=tk%VERSION%"
set "TCLDIR=..\..\%TCL%"
echo %time% > Build.log
echo "%vcvars32_bat%" >> Build.log
call "%vcvars32_bat%" >> Build.log 2>&1
echo %time% >> Build.log
call:JMP_Build32 %TCL% symbols TCLDebug32.log
call:JMP_Build32 %TCL% "" TCLRelease32.log
call:JMP_Build32 %TK% symbols TKDebug32.log
call:JMP_Build32 %TK% "" TKRelease32.log
exit 0
:JMP_Build32
echo Building '%1' '%2' '%3'
cd %1\win\
echo %time%> ..\..\%3
del nmakehlp.exe >> ..\..\%3 2>&1
nmake -f makefile.vc OPTS=%2 >> ..\..\%3 2>&1
echo %time%>> ..\..\%3
cd ..\..\
goto:eof
The call to nmake -f makefile.vc results in subsequent calls to other makefile.vc files in sister directories. If you face similar issues you should include those in your search.

Preprocessing Failed

I've been trying to compile Ogre for weeks now, alternately trying to use the precompiled version (which was apparently incompatible with the same compiler it was built with), and now I've figured enough was enough. I ran CMake 2.8.11 on the Ogre 1.8.1 source to generate the Code::Blocks 12.11 project. Pressing the "compile" button in C::B gives me the following:
Build log:
-------------- Build: all in OGRE (compiler: GNU GCC Compiler)---------------
Running command: C:\MinGW\bin\mingw32-make.exe -f "C:/Users/Conscious Code/Desktop/ogre_src_v1-8-1/Makefile" VERBOSE=1 all
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -H"C:\Users\Conscious Code\Desktop\ogre_src_v1-8-1" -B"C:\Users\Conscious Code\Desktop\ogre_src_v1-8-1" --check-build-system CMakeFiles\Makefile.cmake 0
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_progress_start "C:\Users\Conscious Code\Desktop\ogre_src_v1-8-1\CMakeFiles" "C:\Users\Conscious Code\Desktop\ogre_src_v1-8-1\CMakeFiles\progress.marks"
C:/MinGW/bin/mingw32-make -f CMakeFiles\Makefile2 all
mingw32-make[1]: Entering directory `C:/Users/Conscious Code/Desktop/ogre_src_v1-8-1'
C:/MinGW/bin/mingw32-make -f OgreMain\CMakeFiles\OgreMain.dir\build.make OgreMain/CMakeFiles/OgreMain.dir/depend
mingw32-make[2]: Entering directory `C:/Users/Conscious Code/Desktop/ogre_src_v1-8-1'
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_progress_report "C:\Users\Conscious Code\Desktop\ogre_src_v1-8-1\CMakeFiles"
[ 0%]
Generating OgreWin32Resources.rc.obj
cd /d OgreMain && "C:\Program Files (x86)\CodeBlocks\MinGW\bin\windres.exe" "-IC:/Users/Conscious Code/Desktop/ogre_src_v1-8-1/OgreMain/src/WIN32" "-iC:/Users/Conscious Code/Desktop/ogre_src_v1-8-1/OgreMain/src/WIN32/OgreWin32Resources.rc" "-oC:/Users/Conscious Code/Desktop/ogre_src_v1-8-1/OgreMain/OgreWin32Resources.rc.obj"
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files (x86)\CodeBlocks\MinGW\bin\windres.exe: preprocessing failed.
mingw32-make[2]: *** [OgreMain/OgreWin32Resources.rc.obj] Error 1
mingw32-make[1]: *** [OgreMain/CMakeFiles/OgreMain.dir/all] Error 2
mingw32-make: *** [all] Error 2
mingw32-make[2]: Leaving directory `C:/Users/Conscious Code/Desktop/ogre_src_v1-8-1'
mingw32-make[1]: Leaving directory `C:/Users/Conscious Code/Desktop/ogre_src_v1-8-1'
Process terminated with status 2 (0 minutes, 1 seconds)
1 errors, 0 warnings (0 minutes, 1 seconds)
Build messages:
=== OGRE, all ===
preprocessing failed.
=== Build finished: 1 errors, 0 warnings (0 minutes, 1 seconds) ===
From the error, it seems like some kind of issue with windres when it's generating OgreWin32Resource.rc.obj. What can I do to fix this?
Turns out it was a combination issue of spaces in the project path (which I had tried to fix earlier, getting the error anyway) and a improperly set CXX_MAKE_COMPILER that led to the "Program Files (x86)" folder (which was wrong anyway, I had a newer compiler in C:\MinGW). Fixing that, compilation went a little longer and then snagged on an issue of dependency architectures.
After realizing FreeImage required Visual Studio to compile, I threw in the towel and switched to Irrlicht. Compiling a library has never been more simple than with Irrlicht...
tl;dr: Irrlicht is just plain better for ease of compilation. Ogre will try its hardest to murder you.