I tried to configure my VS2013 to work with CPLEX 12.6 on a 32bit, I succeed to add it.
I read this (VS2012) but I can't find a clear solution with VS2013
VS2013 shows me a lot of errors like :
Error 2 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in Source.obj C:\Users\juste 3al faza\documents\visual studio 2013\Projects\cplex\ilocplex.lib(ilocplex.obj) cplex
and
Error 1 error LNK2038: mismatch detected for '_MSC_VER': value '1700' doesn't match value '1800' in Source.obj C:\Users\juste 3al faza\documents\visual studio 2013\Projects\cplex\ilocplex.lib(ilocplex.obj) cplex
and
Error 168 error LNK2019: unresolved external symbol "__declspec(dllimport) public: virtual void __thiscall std::basic_ostream >::_Add_vtordisp2(void)" (__imp_?_Add_vtordisp2#?$basic_ostream#DU?$char_traits#D#std###std##UAEXXZ) referenced in function "[thunk]:public: virtual void __thiscall std::basic_ostream >::_Add_vtordisp2`vtordisp{4294967292,8}' (void)" (?_Add_vtordisp2#?$basic_ostream#DU?$char_traits#D#std###std##$4PPPPPPPM#7AEXXZ) C:\Users\juste 3al faza\documents\visual studio 2013\Projects\cplex\concert.lib(iloenv.obj) cplex
and
Error 143 error LNK2005: _vsprintf_s already defined in LIBCMT.lib(vsnprnc.obj) C:\Users\juste 3al faza\documents\visual studio 2013\Projects\cplex\MSVCRT.lib(MSVCR120.dll) cplex
I don't know if Cplex 12.6 compatible with VS2013, but I download Cplex 12.6 and I install it without any errors on win8
So, Any help plz!!!
There isn't yet a version of CPLEX for VS2013. See the previously asked question Need more explanation on LNK2038 mismatch dectected for '_MSC_VER', and in particular, the response from Xavier Nodet that points to the system requirements info on the IBM website.
Related
I downloaded and extracted Crypto++ in C:\cryptopp. I used Visual Studio Express 2012 to build all the projects inside (as instructed in readme), and everything was built successfully. Then I made a test project in some other folder and added cryptolib as a dependency. After that, I added the include path so I can easily include all the headers. When I tried to compile, I got an error about unresolved symbols.
To remedy that, I added C:\cryptopp\Win32\Output\Debug\cryptlib.lib to link additional dependencies. Now I get this error:
Error 1 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(cryptlib.obj) CryptoTest
Error 2 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(iterhash.obj) CryptoTest
Error 3 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(sha.obj) CryptoTest
Error 4 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(pch.obj) CryptoTest
Error 5 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(misc.obj) CryptoTest
Error 6 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(queue.obj) CryptoTest
Error 7 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(algparam.obj) CryptoTest
Error 8 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(filters.obj) CryptoTest
Error 9 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(fips140.obj) CryptoTest
Error 10 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(cpu.obj) CryptoTest
Error 11 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(mqueue.obj) CryptoTest
I also get:
Error 12 error LNK2005: "public: __thiscall std::_Container_base12::_Container_base12(void)" (??0_Container_base12#std##QAE#XZ) already defined in cryptlib.lib(cryptlib.obj) C:\Data\Work\C++ VS\CryptoTest\CryptoTest\msvcprtd.lib(MSVCP110D.dll) CryptoTest
Error 13 error LNK2005: "public: __thiscall std::_Container_base12::~_Container_base12(void)" (??1_Container_base12#std##QAE#XZ) already defined in cryptlib.lib(cryptlib.obj) C:\Data\Work\C++ VS\CryptoTest\CryptoTest\msvcprtd.lib(MSVCP110D.dll) CryptoTest
Error 14 error LNK2005: "public: void __thiscall std::_Container_base12::_Orphan_all(void)" (?_Orphan_all#_Container_base12#std##QAEXXZ) already defined in cryptlib.lib(cryptlib.obj) C:\Data\Work\C++ VS\CryptoTest\CryptoTest\msvcprtd.lib(MSVCP110D.dll) CryptoTest
Error 15 error LNK2005: "public: __thiscall std::locale::id::id(unsigned int)" (??0id#locale#std##QAE#I#Z) already defined in cryptlib.lib(iterhash.obj) C:\Data\Work\C++ VS\CryptoTest\CryptoTest\msvcprtd.lib(MSVCP110D.dll) CryptoTest
Warning 16 warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library C:\Data\Work\C++ VS\CryptoTest\CryptoTest\LINK CryptoTest
Error 17 error LNK1169: one or more multiply defined symbols found C:\Data\Work\C++ VS\CryptoTest\Debug\CryptoTest.exe 1 1 CryptoTest
The code I tried to compile was simple (I got this from another site):
#include <iostream>
#include <string>
#include "sha.h"
#include "hex.h"
using namespace std;
string SHA256(string data) {
byte const* pbData = (byte*) data.data();
unsigned int nDataLen = data.size();
byte abDigest[32];
CryptoPP::SHA256().CalculateDigest(abDigest, pbData, nDataLen);
return string((char*)abDigest);
}
int main(void) {
return 0;
}
Any ideas how to fix this? I really only need SHA-256 right now, nothing else.
I am using Windows 7 64 bit, and I downloaded VS C++ today, so it should be the newest version.
(This is already answered in comments, but since it lacks an actual answer, I'm writing this.)
This problem arises in newer versions of Visual C++ (the older versions usually just silently linked the program and it would crash and burn at run time.) It means that some of the libraries you are linking with your program (or even some of the source files inside your program itself) are using different versions of the CRT (the C RunTime library.)
To correct this error, you need to go into your Project Properties (and/or those of the libraries you are using,) then into C/C++, then Code Generation, and check the value of Runtime Library; this should be exactly the same for all the files and libraries you are linking together. (The rules are a little more relaxed for linking with DLLs, but I'm not going to go into the "why" and into more details here.)
There are currently four options for this setting:
Multithreaded Debug
Multithreaded Debug DLL
Multithreaded Release
Multithreaded Release DLL
Your particular problem seems to stem from you linking a library built with "Multithreaded Debug" (i.e. static multithreaded debug CRT) against a program that is being built using the "Multithreaded Debug DLL" setting (i.e. dynamic multithreaded debug CRT.) You should change this setting either in the library, or in your program. For now, I suggest changing this in your program.
Note that since Visual Studio projects use different sets of project settings for debug and release builds (and 32/64-bit builds) you should make sure the settings match in all of these project configurations.
For (some) more information, you can see these (linked from a comment above):
Linker Tools Warning LNK4098 on MSDN
/MD, /ML, /MT, /LD (Use Run-Time Library) on MSDN
Build errors with VC11 Beta - mixing MTd libs with MDd exes fail to link on Bugzilla#Mozilla
UPDATE: (This is in response to a comment that asks for the reason that this much care must be taken.)
If two pieces of code that we are linking together are themselves linking against and using the standard library, then the standard library must be the same for both of them, unless great care is taken about how our two code pieces interact and pass around data. Generally, I would say that for almost all situations just use the exact same version of the standard library runtime (regarding debug/release, threads, and obviously the version of Visual C++, among other things like iterator debugging, etc.)
The most important part of the problem is this: having the same idea about the size of objects on either side of a function call.
Consider for example that the above two pieces of code are called A and B. A is compiled against one version of the standard library, and B against another. In A's view, some random object that a standard function returns to it (e.g. a block of memory or an iterator or a FILE object or whatever) has some specific size and layout (remember that structure layout is determined and fixed at compile time in C/C++.) For any of several reasons, B's idea of the size/layout of the same objects is different (it can be because of additional debug information, natural evolution of data structures over time, etc.)
Now, if A calls the standard library and gets an object back, then passes that object to B, and B touches that object in any way, chances are that B will mess that object up (e.g. write the wrong field, or past the end of it, etc.)
The above isn't the only kind of problems that can happen. Internal global or static objects in the standard library can cause problems too. And there are more obscure classes of problems as well.
All this gets weirder in some aspects when using DLLs (dynamic runtime library) instead of libs (static runtime library.)
This situation can apply to any library used by two pieces of code that work together, but the standard library gets used by most (if not almost all) programs, and that increases the chances of clash.
What I've described is obviously a watered down and simplified version of the actual mess that awaits you if you mix library versions. I hope that it gives you an idea of why you shouldn't do it!
I had this problem along with mismatch in ITERATOR_DEBUG_LEVEL.
As a sunday-evening problem after all seemed ok and good to go, I was put out for some time.
Working in de VS2017 IDE (Solution Explorer) I had recently added/copied a sourcefile reference to my project (ctrl-drag) from another project. Looking into properties->C/C++/Preprocessor - at source file level, not project level - I noticed that in a Release configuration _DEBUG was specified instead of NDEBUG for this source file.
Which was all the change needed to get rid of the problem.
I downloaded and extracted Crypto++ in C:\cryptopp. I used Visual Studio Express 2012 to build all the projects inside (as instructed in readme), and everything was built successfully. Then I made a test project in some other folder and added cryptolib as a dependency.
The conversion was probably not successful. The only thing that was successful was the running of VCUpgrade. The actual conversion itself failed but you don't know until you experience the errors you are seeing. For some of the details, see Visual Studio on the Crypto++ wiki.
Any ideas how to fix this?
To resolve your issues, you should download vs2010.zip if you want static C/C++ runtime linking (/MT or /MTd), or vs2010-dynamic.zip if you want dynamic C/C++ runtime linking (/MT or /MTd). Both fix the latent, silent failures produced by VCUpgrade.
vs2010.zip, vs2010-dynamic.zip and vs2005-dynamic.zip are built from the latest GitHub sources. As of this writing (JUN 1 2016), that's effectively pre-Crypto++ 5.6.4. If you are using the ZIP files with a down level Crypto++, like 5.6.2 or 5.6.3, then you will run into minor problems.
There are two minor problems I am aware. First is a rename of bench.cpp to bench1.cpp. Its error is either:
C1083: Cannot open source file: 'bench1.cpp': No such file or directory
LNK2001: unresolved external symbol "void __cdecl OutputResultOperations(char const *,char const *,bool,unsigned long,double)" (?OutputResultOperations##YAXPBD0_NKN#Z)
The fix is to either (1) open cryptest.vcxproj in notepad, find bench1.cpp, and then rename it to bench.cpp. Or (2) rename bench.cpp to bench1.cpp on the filesystem. Please don't delete this file.
The second problem is a little trickier because its a moving target. Down level releases, like 5.6.2 or 5.6.3, are missing the latest classes available in GitHub. The missing class files include HKDF (5.6.3), RDRAND (5.6.3), RDSEED (5.6.3), ChaCha (5.6.4), BLAKE2 (5.6.4), Poly1305 (5.6.4), etc.
The fix is to remove the missing source files from the Visual Studio project files since they don't exist for the down level releases.
Another option is to add the missing class files from the latest sources, but there could be complications. For example, many of the sources subtly depend upon the latest config.h, cpu.h and cpu.cpp. The "subtlety" is you won't realize you are getting an under-performing class.
An example of under-performing class is BLAKE2. config.h adds compile time ARM-32 and ARM-64 detection. cpu.h and cpu.cpp adds runtime ARM instruction detection, which depends upon compile time detection. If you add BLAKE2 without the other files, then none of the detection occurs and you get a straight C/C++ implementation. You probably won't realize you are missing the NEON opportunity, which runs around 9 to 12 cycles-per-byte versus 40 cycles-per-byte or so for vanilla C/C++.
Issue can be solved by adding CRT of msvcrtd.lib in the linker library.
Because cryptlib.lib used CRT version of debug.
I have some problems integrating CryptoPP in Visual Studio. I've followed some tutorials without success, and when I try to compile the project I get hundreads of errors.
What I did:
I builded cryptlib with both debug and release configurations, generating the cryptlib.lib files
I added the dependencies to the .lib files that I've just generated
I added the paths to the .h files
When compiling my project, I get more than 100 errors of the type LNKxxxx, I don't know if I did something wrong while compiling the libraries, or if I miss something, but I'm completely stuck.
--- EDIT ---
As requested, here are some of the errors I get
Error LNK2038 mismatch detected for 'RuntimeLibrary': the value
'MTd_StaticDebug' does not match the value 'MDd_DynamicDebug' in
pwmc.obj pwmc C:\Users\aless\Documents\C\pwm\pwmc\pwmc\cryptlib.lib(rijndael.obj) 1
Error LNK2005 "protected: __cdecl std::basic_streambuf<char,struct
std::char_traits >::basic_streambuf<char,struct
std::char_traits >(void)"
(??0?$basic_streambuf#DU?$char_traits#D#std###std##IEAA#XZ) already
defined in
cryptlib.lib(cryptlib.obj) pwmc C:\Users\aless\Documents\C\pwm\pwmc\pwmc\msvcprtd.lib(MSVCP140D.dll) 1
Error LNK2005 "private: static class std::locale::_Locimp * __cdecl
std::locale::_Init(bool)" (?_Init#locale#std##CAPEAV_Locimp#12#_N#Z)
already defined in
msvcprtd.lib(MSVCP140D.dll) pwmc C:\Users\aless\Documents\C\pwm\pwmc\pwmc\libcpmtd.lib(locale0.obj) 1
Since my Visual Studio is not in english I translated the errors myself, but I don't know the exact/correct translation, I hope that is clear enough anyway.
Thanks in advance to everyone.
PS
I don't think my code is the problem, to test if all were working i used this sample code
While compiling a current project I get a bunch (about 80) of Linker errors that I don't know anymore how to debug further.
I am using Visual Studio 2019. It's a C++ project compiled on Windows 10.
A lot of them come from a library called libcpmt.lib.
There are 2 types of error related to the library:
First it claims some function s are alredy defined in msvcprt.lib(MSVCP140.dll) (which is strange since I am using Visual Studio 2019 v142)
Error LNK2005 "protected: __cdecl std::locale::facet::facet(unsigned __int64)" (??0facet#locale#std##IEAA#_K#Z) already defined in msvcprt.lib(MSVCP140.dll) DataConverter path_to_project\libcpmt.lib(locale0.obj)
and second it claims that libcpmt.lib is compiled statically while my project used dynamically linked libraries.
Error LNK2038 mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in annotation.obj DataConverter path_to_project\libcpmt.lib(xstol.obj) 1
The same error also appears on a library called mpirxx.lib
Error LNK2038 mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in annotation.obj DataConverter path_to_project\mpirxx.lib(osmpf.obj) 1
and
Error LNK2005 "public: void __cdecl std::basic_ostream<char,struct std::char_traits<char> >::_Osfx(void)" (?_Osfx#?$basic_ostream#DU?$char_traits#D#std###std##QEAAXXZ) already defined in mpirxx.lib(osmpf.obj) DataConverter path_to_project\msvcprt.lib(MSVCP140.dll) 1
From what little I found about the lib on the internet it appears to be included when your C++->Code Generation->Runtime Library is set to MT, but my settings are set to MD.
I am including a lot of external libraries in my project:
flann.lib
flann_cpp.lib
Qt5Widgets.lib
qtmain.lib
Qt5Gui.lib
Qt5Core.lib
libboost_atomic-vc142-mt-x64-1_74.lib
libboost_chrono-vc142-mt-x64-1_74.lib
libboost_container-vc142-mt-x64-1_74.lib
libboost_context-vc142-mt-x64-1_74.lib
libboost_contract-vc142-mt-x64-1_74.lib
libboost_coroutine-vc142-mt-x64-1_74.lib
libboost_date_time-vc142-mt-x64-1_74.lib
libboost_exception-vc142-mt-x64-1_74.lib
libboost_fiber-vc142-mt-x64-1_74.lib
libboost_graph-vc142-mt-x64-1_74.lib
libboost_iostreams-vc142-mt-x64-1_74.lib
libboost_locale-vc142-mt-x64-1_74.lib
libboost_log_setup-vc142-mt-x64-1_74.lib
libboost_log-vc142-mt-x64-1_74.lib
libboost_math_c99f-vc142-mt-x64-1_74.lib
libboost_math_c99l-vc142-mt-x64-1_74.lib
libboost_math_c99-vc142-mt-x64-1_74.lib
libboost_math_tr1f-vc142-mt-x64-1_74.lib
libboost_math_tr1l-vc142-mt-x64-1_74.lib
libboost_math_tr1-vc142-mt-x64-1_74.lib
libboost_nowide-vc142-mt-x64-1_74.lib
libboost_numpy37-vc142-mt-x64-1_74.lib
libboost_prg_exec_monitor-vc142-mt-x64-1_74.lib
libboost_program_options-vc142-mt-x64-1_74.lib
libboost_python37-vc142-mt-x64-1_74.lib
libboost_random-vc142-mt-x64-1_74.lib
libboost_regex-vc142-mt-x64-1_74.lib
libboost_serialization-vc142-mt-x64-1_74.lib
libboost_stacktrace_noop-vc142-mt-x64-1_74.lib
libboost_stacktrace_windbg_cached-vc142-mt-x64-1_74.lib
libboost_stacktrace_windbg-vc142-mt-x64-1_74.lib
libboost_system-vc142-mt-x64-1_74.lib
libboost_test_exec_monitor-vc142-mt-x64-1_74.lib
libboost_thread-vc142-mt-x64-1_74.lib
libboost_timer-vc142-mt-x64-1_74.lib
libboost_type_erasure-vc142-mt-x64-1_74.lib
libboost_unit_test_framework-vc142-mt-x64-1_74.lib
libboost_wave-vc142-mt-x64-1_74.lib
libboost_wserialization-vc142-mt-x64-1_74.lib
bz2.lib
libpng16.lib
lz4.lib
lzma.lib
mpfr.lib
mpir.lib
mpirxx.lib
qhullcpp.lib
xxhash.lib
zlib.lib
zstd.lib
gmp.lib
glew32.lib
glew32s.lib
opencv_world440.lib
vtkChartsCore-9.0.lib
vtkCommonColor-9.0.lib
vtkCommonComputationalGeometry-9.0.lib
vtkCommonCore-9.0.lib
vtkCommonDataModel-9.0.lib
vtkCommonExecutionModel-9.0.lib
vtkCommonMath-9.0.lib
vtkCommonMisc-9.0.lib
vtkCommonSystem-9.0.lib
vtkCommonTransforms-9.0.lib
vtkDICOMParser-9.0.lib
vtkDomainsChemistry-9.0.lib
vtkdoubleconversion-9.0.lib
vtkexodusII-9.0.lib
vtkexpat-9.0.lib
vtkFiltersAMR-9.0.lib
vtkFiltersCore-9.0.lib
vtkFiltersExtraction-9.0.lib
vtkFiltersFlowPaths-9.0.lib
vtkFiltersGeneral-9.0.lib
vtkFiltersGeneric-9.0.lib
vtkFiltersGeometry-9.0.lib
vtkFiltersHybrid-9.0.lib
vtkFiltersHyperTree-9.0.lib
vtkFiltersImaging-9.0.lib
vtkFiltersModeling-9.0.lib
vtkFiltersParallel-9.0.lib
vtkFiltersParallelImaging-9.0.lib
vtkFiltersPoints-9.0.lib
vtkFiltersProgrammable-9.0.lib
vtkFiltersSelection-9.0.lib
vtkFiltersSMP-9.0.lib
vtkFiltersSources-9.0.lib
vtkFiltersStatistics-9.0.lib
vtkFiltersTexture-9.0.lib
vtkFiltersTopology-9.0.lib
vtkFiltersVerdict-9.0.lib
vtkfreetype-9.0.lib
vtkGeovisCore-9.0.lib
vtkgl2ps-9.0.lib
vtkglew-9.0.lib
vtkhdf5-9.0.lib
vtkhdf5_hl-9.0.lib
vtkImagingColor-9.0.lib
vtkImagingCore-9.0.lib
vtkImagingFourier-9.0.lib
vtkImagingGeneral-9.0.lib
vtkImagingHybrid-9.0.lib
vtkImagingMath-9.0.lib
vtkImagingMorphological-9.0.lib
vtkImagingSources-9.0.lib
vtkImagingStatistics-9.0.lib
vtkImagingStencil-9.0.lib
vtkInfovisCore-9.0.lib
vtkInfovisLayout-9.0.lib
vtkInteractionImage-9.0.lib
vtkInteractionStyle-9.0.lib
vtkInteractionWidgets-9.0.lib
vtkIOAMR-9.0.lib
vtkIOAsynchronous-9.0.lib
vtkIOCityGML-9.0.lib
vtkIOCore-9.0.lib
vtkIOEnSight-9.0.lib
vtkIOExodus-9.0.lib
vtkIOExport-9.0.lib
vtkIOExportGL2PS-9.0.lib
vtkIOExportPDF-9.0.lib
vtkIOGeometry-9.0.lib
vtkIOImage-9.0.lib
vtkIOImport-9.0.lib
vtkIOInfovis-9.0.lib
vtkIOLegacy-9.0.lib
vtkIOLSDyna-9.0.lib
vtkIOMINC-9.0.lib
vtkIOMotionFX-9.0.lib
vtkIOMovie-9.0.lib
vtkIONetCDF-9.0.lib
vtkIOOggTheora-9.0.lib
vtkIOParallel-9.0.lib
vtkIOParallelXML-9.0.lib
vtkIOPLY-9.0.lib
vtkIOSegY-9.0.lib
vtkIOSQL-9.0.lib
vtkIOTecplotTable-9.0.lib
vtkIOVeraOut-9.0.lib
vtkIOVideo-9.0.lib
vtkIOXML-9.0.lib
vtkIOXMLParser-9.0.lib
vtkjpeg-9.0.lib
vtkjsoncpp-9.0.lib
vtklibharu-9.0.lib
vtklibproj-9.0.lib
vtklibxml2-9.0.lib
vtkloguru-9.0.lib
vtklz4-9.0.lib
vtklzma-9.0.lib
vtkmetaio-9.0.lib
vtknetcdf-9.0.lib
vtkogg-9.0.lib
vtkParallelCore-9.0.lib
vtkParallelDIY-9.0.lib
vtkpng-9.0.lib
vtkpugixml-9.0.lib
vtkRenderingAnnotation-9.0.lib
vtkRenderingContext2D-9.0.lib
vtkRenderingCore-9.0.lib
vtkRenderingFreeType-9.0.lib
vtkRenderingGL2PSOpenGL2-9.0.lib
vtkRenderingImage-9.0.lib
vtkRenderingLabel-9.0.lib
vtkRenderingLOD-9.0.lib
vtkRenderingOpenGL2-9.0.lib
vtkRenderingSceneGraph-9.0.lib
vtkRenderingUI-9.0.lib
vtkRenderingVolume-9.0.lib
vtkRenderingVolumeOpenGL2-9.0.lib
vtkRenderingVtkJS-9.0.lib
vtksqlite-9.0.lib
vtksys-9.0.lib
vtkTestingRendering-9.0.lib
vtktheora-9.0.lib
vtktiff-9.0.lib
vtkverdict-9.0.lib
vtkViewsContext2D-9.0.lib
vtkViewsCore-9.0.lib
vtkViewsInfovis-9.0.lib
vtkWrappingTools-9.0.lib
vtkzlib-9.0.lib
pcl_common.lib
pcl_features.lib
pcl_filters.lib
pcl_io.lib
pcl_io_ply.lib
pcl_kdtree.lib
pcl_keypoints.lib
pcl_ml.lib
pcl_octree.lib
pcl_recognition.lib
pcl_registration.lib
pcl_search.lib
pcl_segmentation.lib
pcl_sample_consensus.lib
pcl_stereo.lib
pcl_surface.lib
pcl_tracking.lib
Does anybody have an idea how to further debug or fix these issues?
PS: I currently have another error which is likely unrelated but I wanted to include it for completeness. The linker can't find the lib for loadPolygonFilePLY. Likely I'm just missing an additional pcl lib. If anybody happens to know how it's called please also comment:
Error LNK2001 unresolved external symbol "int __cdecl pcl::io::loadPolygonFilePLY(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,struct pcl::PolygonMesh &)" (?loadPolygonFilePLY#io#pcl##YAHAEBV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std##AEAUPolygonMesh#2##Z)
In case somebody comes along a similar issue. These was a library in my included libraries that was using the static linkage (mpirxx.lib). A good way to debug this is to put /VERBOSE:LIB in your linker options. Then build and go to your Output windows where you can see which is the first library to trigger this error chain.
Thanks to Alan Birtles for the help.
I am coding some games in C++ and have to use a graphical engine called PlayLib, made in the university near me, but unfortunately when I run this Main.cpp file with all the "includes" and "additional libraries", it gives me the same error! (on Visual Studio 2015, while on VC++2010 it works normally - but I prefer the first one). The error output message is the following:
1>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/LTCG' specification
1>Main.obj : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:LBR' specification
1>PlayLib.lib(Graphics.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1600' doesn't match value '1900' in Main.obj
1>PlayLib.lib(Graphics.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in Main.obj
1>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>PlayLib.lib(Graphics.obj) : error LNK2001: unresolved external symbol __imp__vsprintf
1>PlayLib.lib(Graphics.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::exception::exception(char const * const &)" (__imp_??0exception#std##QAE#ABQBD#Z)
1>c:\users\casa\documents\visual studio 2015\Projects\BatalhaNaval\Debug\BatalhaNaval.exe : fatal error LNK1120: 2 unresolved externals
The main.cpp and header.h are all correct, so I think the problem may lie on the project settings or on the library itself. Please help me so I can work on my Battleship game - I am desperate to put my hands on it haha
Thanks - Guilherme
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs
I had same warning using some libraries. What helped me was going through #include directives in whole project and changing old style includes to a new style ones:
for example:
math.h i had to change to cmath
stdio.h, to cstdio ad so on.
If that doesn't help then probably you have an issue with runtime libraries. If you use visual studio you can play with them in project properties->C/C++->Code generation->Runtime Libraries.
I downloaded and extracted Crypto++ in C:\cryptopp. I used Visual Studio Express 2012 to build all the projects inside (as instructed in readme), and everything was built successfully. Then I made a test project in some other folder and added cryptolib as a dependency. After that, I added the include path so I can easily include all the headers. When I tried to compile, I got an error about unresolved symbols.
To remedy that, I added C:\cryptopp\Win32\Output\Debug\cryptlib.lib to link additional dependencies. Now I get this error:
Error 1 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(cryptlib.obj) CryptoTest
Error 2 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(iterhash.obj) CryptoTest
Error 3 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(sha.obj) CryptoTest
Error 4 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(pch.obj) CryptoTest
Error 5 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(misc.obj) CryptoTest
Error 6 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(queue.obj) CryptoTest
Error 7 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(algparam.obj) CryptoTest
Error 8 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(filters.obj) CryptoTest
Error 9 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(fips140.obj) CryptoTest
Error 10 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(cpu.obj) CryptoTest
Error 11 error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in program.obj C:\Data\Work\C++ VS\CryptoTest\CryptoTest\cryptlib.lib(mqueue.obj) CryptoTest
I also get:
Error 12 error LNK2005: "public: __thiscall std::_Container_base12::_Container_base12(void)" (??0_Container_base12#std##QAE#XZ) already defined in cryptlib.lib(cryptlib.obj) C:\Data\Work\C++ VS\CryptoTest\CryptoTest\msvcprtd.lib(MSVCP110D.dll) CryptoTest
Error 13 error LNK2005: "public: __thiscall std::_Container_base12::~_Container_base12(void)" (??1_Container_base12#std##QAE#XZ) already defined in cryptlib.lib(cryptlib.obj) C:\Data\Work\C++ VS\CryptoTest\CryptoTest\msvcprtd.lib(MSVCP110D.dll) CryptoTest
Error 14 error LNK2005: "public: void __thiscall std::_Container_base12::_Orphan_all(void)" (?_Orphan_all#_Container_base12#std##QAEXXZ) already defined in cryptlib.lib(cryptlib.obj) C:\Data\Work\C++ VS\CryptoTest\CryptoTest\msvcprtd.lib(MSVCP110D.dll) CryptoTest
Error 15 error LNK2005: "public: __thiscall std::locale::id::id(unsigned int)" (??0id#locale#std##QAE#I#Z) already defined in cryptlib.lib(iterhash.obj) C:\Data\Work\C++ VS\CryptoTest\CryptoTest\msvcprtd.lib(MSVCP110D.dll) CryptoTest
Warning 16 warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library C:\Data\Work\C++ VS\CryptoTest\CryptoTest\LINK CryptoTest
Error 17 error LNK1169: one or more multiply defined symbols found C:\Data\Work\C++ VS\CryptoTest\Debug\CryptoTest.exe 1 1 CryptoTest
The code I tried to compile was simple (I got this from another site):
#include <iostream>
#include <string>
#include "sha.h"
#include "hex.h"
using namespace std;
string SHA256(string data) {
byte const* pbData = (byte*) data.data();
unsigned int nDataLen = data.size();
byte abDigest[32];
CryptoPP::SHA256().CalculateDigest(abDigest, pbData, nDataLen);
return string((char*)abDigest);
}
int main(void) {
return 0;
}
Any ideas how to fix this? I really only need SHA-256 right now, nothing else.
I am using Windows 7 64 bit, and I downloaded VS C++ today, so it should be the newest version.
(This is already answered in comments, but since it lacks an actual answer, I'm writing this.)
This problem arises in newer versions of Visual C++ (the older versions usually just silently linked the program and it would crash and burn at run time.) It means that some of the libraries you are linking with your program (or even some of the source files inside your program itself) are using different versions of the CRT (the C RunTime library.)
To correct this error, you need to go into your Project Properties (and/or those of the libraries you are using,) then into C/C++, then Code Generation, and check the value of Runtime Library; this should be exactly the same for all the files and libraries you are linking together. (The rules are a little more relaxed for linking with DLLs, but I'm not going to go into the "why" and into more details here.)
There are currently four options for this setting:
Multithreaded Debug
Multithreaded Debug DLL
Multithreaded Release
Multithreaded Release DLL
Your particular problem seems to stem from you linking a library built with "Multithreaded Debug" (i.e. static multithreaded debug CRT) against a program that is being built using the "Multithreaded Debug DLL" setting (i.e. dynamic multithreaded debug CRT.) You should change this setting either in the library, or in your program. For now, I suggest changing this in your program.
Note that since Visual Studio projects use different sets of project settings for debug and release builds (and 32/64-bit builds) you should make sure the settings match in all of these project configurations.
For (some) more information, you can see these (linked from a comment above):
Linker Tools Warning LNK4098 on MSDN
/MD, /ML, /MT, /LD (Use Run-Time Library) on MSDN
Build errors with VC11 Beta - mixing MTd libs with MDd exes fail to link on Bugzilla#Mozilla
UPDATE: (This is in response to a comment that asks for the reason that this much care must be taken.)
If two pieces of code that we are linking together are themselves linking against and using the standard library, then the standard library must be the same for both of them, unless great care is taken about how our two code pieces interact and pass around data. Generally, I would say that for almost all situations just use the exact same version of the standard library runtime (regarding debug/release, threads, and obviously the version of Visual C++, among other things like iterator debugging, etc.)
The most important part of the problem is this: having the same idea about the size of objects on either side of a function call.
Consider for example that the above two pieces of code are called A and B. A is compiled against one version of the standard library, and B against another. In A's view, some random object that a standard function returns to it (e.g. a block of memory or an iterator or a FILE object or whatever) has some specific size and layout (remember that structure layout is determined and fixed at compile time in C/C++.) For any of several reasons, B's idea of the size/layout of the same objects is different (it can be because of additional debug information, natural evolution of data structures over time, etc.)
Now, if A calls the standard library and gets an object back, then passes that object to B, and B touches that object in any way, chances are that B will mess that object up (e.g. write the wrong field, or past the end of it, etc.)
The above isn't the only kind of problems that can happen. Internal global or static objects in the standard library can cause problems too. And there are more obscure classes of problems as well.
All this gets weirder in some aspects when using DLLs (dynamic runtime library) instead of libs (static runtime library.)
This situation can apply to any library used by two pieces of code that work together, but the standard library gets used by most (if not almost all) programs, and that increases the chances of clash.
What I've described is obviously a watered down and simplified version of the actual mess that awaits you if you mix library versions. I hope that it gives you an idea of why you shouldn't do it!
I had this problem along with mismatch in ITERATOR_DEBUG_LEVEL.
As a sunday-evening problem after all seemed ok and good to go, I was put out for some time.
Working in de VS2017 IDE (Solution Explorer) I had recently added/copied a sourcefile reference to my project (ctrl-drag) from another project. Looking into properties->C/C++/Preprocessor - at source file level, not project level - I noticed that in a Release configuration _DEBUG was specified instead of NDEBUG for this source file.
Which was all the change needed to get rid of the problem.
I downloaded and extracted Crypto++ in C:\cryptopp. I used Visual Studio Express 2012 to build all the projects inside (as instructed in readme), and everything was built successfully. Then I made a test project in some other folder and added cryptolib as a dependency.
The conversion was probably not successful. The only thing that was successful was the running of VCUpgrade. The actual conversion itself failed but you don't know until you experience the errors you are seeing. For some of the details, see Visual Studio on the Crypto++ wiki.
Any ideas how to fix this?
To resolve your issues, you should download vs2010.zip if you want static C/C++ runtime linking (/MT or /MTd), or vs2010-dynamic.zip if you want dynamic C/C++ runtime linking (/MT or /MTd). Both fix the latent, silent failures produced by VCUpgrade.
vs2010.zip, vs2010-dynamic.zip and vs2005-dynamic.zip are built from the latest GitHub sources. As of this writing (JUN 1 2016), that's effectively pre-Crypto++ 5.6.4. If you are using the ZIP files with a down level Crypto++, like 5.6.2 or 5.6.3, then you will run into minor problems.
There are two minor problems I am aware. First is a rename of bench.cpp to bench1.cpp. Its error is either:
C1083: Cannot open source file: 'bench1.cpp': No such file or directory
LNK2001: unresolved external symbol "void __cdecl OutputResultOperations(char const *,char const *,bool,unsigned long,double)" (?OutputResultOperations##YAXPBD0_NKN#Z)
The fix is to either (1) open cryptest.vcxproj in notepad, find bench1.cpp, and then rename it to bench.cpp. Or (2) rename bench.cpp to bench1.cpp on the filesystem. Please don't delete this file.
The second problem is a little trickier because its a moving target. Down level releases, like 5.6.2 or 5.6.3, are missing the latest classes available in GitHub. The missing class files include HKDF (5.6.3), RDRAND (5.6.3), RDSEED (5.6.3), ChaCha (5.6.4), BLAKE2 (5.6.4), Poly1305 (5.6.4), etc.
The fix is to remove the missing source files from the Visual Studio project files since they don't exist for the down level releases.
Another option is to add the missing class files from the latest sources, but there could be complications. For example, many of the sources subtly depend upon the latest config.h, cpu.h and cpu.cpp. The "subtlety" is you won't realize you are getting an under-performing class.
An example of under-performing class is BLAKE2. config.h adds compile time ARM-32 and ARM-64 detection. cpu.h and cpu.cpp adds runtime ARM instruction detection, which depends upon compile time detection. If you add BLAKE2 without the other files, then none of the detection occurs and you get a straight C/C++ implementation. You probably won't realize you are missing the NEON opportunity, which runs around 9 to 12 cycles-per-byte versus 40 cycles-per-byte or so for vanilla C/C++.
Issue can be solved by adding CRT of msvcrtd.lib in the linker library.
Because cryptlib.lib used CRT version of debug.