I have a visual studio 2012 c++ project.
I recently uninstalled it and installed visual studio 2015 and upgraded the project.
When i am building the project, getting error as shown below:
Error LNK2019 unresolved external symbol _memcmp referenced in function
Moreover i have not used anywhere in my code memcmp fucntion.
I used the linker verbose function and could see below in output file:
Found _memcmp
Referenced in MyC++Project.obj
Referenced in libcpmtd.lib(xstrcoll.obj)
Loaded libvcruntimed.lib(__memcmp_.obj)
Two questions here
1.even though i have not used memcmp in my code why i am getting that linker error?
2.why is memcmp being loaded as __memcmp_.obj
I have the following settings also in my project:
1.C++-->Code generation-->Runtime Library is set to /MTd
2.Linker-->Ignore All default libraries is set to nothing
I have tried all the project settings but everything in vain.
I have issue only with this memcmp function which i have not used.
I have used mamcpy and memset and do not have issue with those
Explicitly add vcruntime.lib or other appropriate version of CRT Library to linker parameters (additional dependencies).
When you use memcmp explicitly it is probably handled as intrinsic function and is compiled as inline function.
Try to add vcruntime.lib and ucrt.lib to your additional dependencies. ===> properties->Linker->Input->Additional Dependencies
Sample path of 'vcruntime.lib': "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\vcruntime.lib"
Sample path of 'ucrt.lib' : "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\ucrt\x86\ucrt.lib"
My environment: VS2017 (v141)
I've run into this same problem with a legacy Visual C++ 6.0 nmake file with Visual Studio 2015.
This blog article, Introducing the Universal CRT, describes how the Visual Studio 2015 runtime has been split into more than one library. The runtime is now "split the CRT into two logical parts: The VCRuntime, which contained the compiler support functionality required for things like process startup and exception handling, and a “stable” part that contained all of the purely library parts of the CRT" to allow for easier updates.
So long as you do not link with the /nodefaultlib option, all of the
correct library files will be found when you link your project. If you
link with the /nodefaultlib option, you will need to link several
extra libraries when you link. For example, whereas you previously
might have just linked msvcrt.lib in order to use the CRT DLL, you
will now also need to link vcruntime.lib and ucrt.lib. Here is a table
that shows which libraries you will need to link for each “flavor” of
the libraries:
Release DLLs (/MD ): msvcrt.lib vcruntime.lib ucrt.lib
Debug DLLs (/MDd): msvcrtd.lib vcruntimed.lib ucrtd.lib
Release Static (/MT ): libcmt.lib libvcruntime.lib libucrt.lib
Debug Static (/MTd): libcmtd.lib libvcruntimed.lib libucrtd.lib
See also the Microsoft documentation C runtime (CRT) and C++ Standard Library (STL) .lib files which describes details about the libraries.
See also Microsoft C/C++ change history 2003 - 2015.
Related
Configuration I have
Windows 10 64bit
Visual Studio Community 2017 with Visual C++ 2017
CMake 3.9.0
opencv 3.3.0
Aim
Goal is to build opencv as a static library (.lib) and include into a Visual C++ project which is a DLL. Everything should be compiled for x86 architecture or simply 32bit.
Process
Latest opencv distributive does not contain dll's compiled for 32bit system and therefore, I need to compile own version. According to the opencv 2.4 documentation on "installation in Windows". I have compiled the library with BUILD_SHARED_LIBS option disabled and configured target project as described in "how to build applications with OpenCV inside the Microsoft Visual Studio".
Compilation of my project fails with following errors (totally error count is greater than 800)
Error type 1
LNK2038 mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug'
doesn't match value 'MDd_DynamicDebug' in main.obj
\opencv_core320d.lib(alloc.obj)
Error type 2
LNK2005 "public: void __thiscall std::basic_ostream<char,struct
std::char_traits<char> >::_Osfx(void)" (?_Osfx#?$basic_ostream#DU?
$char_traits#D#std###std##QAEXXZ) already defined in
opencv_core320d.lib(system.obj) \msvcprtd.lib(MSVCP140D.dll)
Error type 3
LNK2001 unresolved external symbol _ippicviHSVToRGB_16u_C3R#24
\opencv_imgproc320d.lib(color.obj)
I believe it may be due to uncoordinated compilation options or erroneous configuration of my project, but because I am heavy Linux user I experience difficulties with setting up these things on Windows.
Update
After I have matched configuration shown in the screen below block of errors about code generation mismatch disappeared, but undefined references are still there.
Thank you for help!
To resolve "Error type 3" add *.lib files from "staticlib" dir to "Linker->Input->Additional Dependencies". For example "_ipp" symbols are defined in "ipp_iw.lib" and "ippicvmt.lib".
Just for info. I successfully built opencv from sources as a static and shared library (as opencv_world3**.lib) using MSVS 2012 and cmake 3.9.0. But also done that with MSVS 2017 community.
PS. Maybe a TYPO but you said that you use opencv 3.3.0 but in error messages there is opencv_core320d.lib
PPS. "Error type 1" is the result of using static debug runtime version in opencv_core (MTd) and dynamic debug runtime in your app (MDd)
I always have the same problems. This is why I have a property sheet ready for use.
The steps to follow for static compilation are:
Remember to Build the INSTALL project in the CMake generated Solution. Let's call $(OPENCV_DIR) the folder where the install happened (usually something like xxx\install). You can create an environment variable for this.
Add in front of [Configuration Properties]->[VC++ Directories]->[Include Directories] $(OPENCV_DIR)\include;. The semicolon is to separate paths.
Add in front of [Configuration Properties]->[VC++ Directories]->[Library Directories] $(OPENCV_DIR)\x86\vc15\staticlib;.
Match the runtime library linkage mode between OpenCV and your project. If you unselect BUILD_SHARED_LIBS by default the CRT is statically linked (/MT for Release or /MTd for Debug). If you want it dynamically linked deselect BUILD_WITH_STATIC_CRT. So, as you already realized, fix it in [Configuration Properties]->[C/C++]->[Code Generation]->[Runtime Library].
Copy all filenames matching *.lib (*d.lib for Debug) and add them in [Configuration Properties]->[Linker]->[Input]->[Additional Dependencies] separated by semicolons.
It's quite painful, so do it once in a Property Sheet and just include it when needed.
I have a Visual C++ project that uses both CUDA and Boost. I have the following environment variables pointing to different libraries:
BOOST64_Lib = c:\boost\1_57_0\lib64-msvc-11.0
CUDA_LIB_PATH = c:\program files (x86)\NVidia\GPU Computing Toolkit\CUDA\v6.5\lib\x64
My VC++ Directories setting includes the following libraries:
$(BOOST64_Lib);$(CUDA_LIB_PATH);$(LibraryPath)
When I compile the project, I get an error saying cudart.lib can't be found. If I move $(CUDA_LIB_PATH) to the beginning of the VC++ Library directories, I get an error saying msvcprtd.lib cannot be found.
msvcprtd.lib exists in the proper place (VC\lib\amd64 under Visual Studio 2012). cudart.lib obviously exists in the CUDA library folder.
I'm using Visual Studio 2013, and the specific project is compiled with the Visual Studio 2012 (v110) Platform Toolset.
I must be missing something really small, that makes the linker complain about different libraries based on the order of library folders, but I can't find what that is.
Either set
CUDA_LIB_PATH = "c:\program files (x86)\NVidia\GPU Computing Toolkit\CUDA\v6.5\lib\x64"
or
LibraryPath = $(BOOST64_Lib);'$(CUDA_LIB_PATH)';$(LibraryPath)
To get informative build log set Tools / Options / Projects And Solutions / Build and Run/MSBuild output verbosity to Normal.
I have a MFC project which uses C++ Rest SDK (Casablanca) under Visual Studio 2012 to implement an http client connection and it can be compiled well.
Then I add a Microsoft unit test project, but I can’t build the unit test project successfully.
In my main project, the environment is set as “Use MFC in a Static Library”, “No Common Language Runtime Support” and “Multi-threaded Debug (/MTd).” And my test project’s environment is same as main project. The error message shows:
“error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U#YAPAXI#Z) already defined in libcpmtd.lib(newaop.obj).”
In addition, I also try to change the test project’s environment to “Common Language Runtime Support (/clr)” and “Multi-threaded Debug DLL (/MDd).” The original error disappears but new error comes:
“error C1189: #error : is not supported when compiling with /clr or /clr:pure. c:\program files (x86)\microsoft visual studio 11.0\vc\include\atomic line 9”
I do not know how to overcome these problems. Can anyone please give me some suggestions or resolutions? Thanks.
The CRT libraries use weak external linkage for the new, delete functions. The MFC libraries also contain new, delete functions. These functions require the MFC libraries to be linked before the CRT library is linked. Please check http://support.microsoft.com/kb/148652
Solution based on VS2005:
go to project>properties>configuration properties>linker>input
add to "Additional dependency" -> Nafxcwd.lib Libcmtd.lib
add to "ignore specific library" -> Nafxcwd.lib;Libcmtd.lib
I have found that by using NuGet Packmanager to get rest sdk i.e. Search for Casablanca and select cpprestsdk.v140.windesktop. This makes sure all the dlls, libs required are referenced.
Please check:
https://github.com/Microsoft/cpprestsdk/wiki/How-to-use-the-C---Rest-SDK-NuGet-package
http://codename26.rssing.com/chan-8623770/all_p85.html
There is a short response from Microsoft regarding this issue:
https://connect.microsoft.com/VisualStudio/feedback/details/470376/odbc-application-linking-with-odbccp32-lib-gets-link-errors-in-vs2010-beta-1?wa=wsignin1.0#tabs
Basically, their response doesn't seem to address the problem.
Our application needs to statically link to the C libraries, but there is a linker error when attempting to do so. Microsoft's answer seems to be "dynamically link instead", but that's not an option. Their alternative is to "Use the version of odbccp32.lib that came with Vista SDK." However, I am unaware as to how to force VisualStudio 2010 to use a different version of the ODBC library?
I just spent the last hour trying every conceivable search through the .vcxproj and .sln files for any references to odbccp32.lib. None. I similarly looked for ODBC. None. Looking at all of the compiler & linker options for the project(s) in question: nothing refers to ODBC whatsoever. The only connection between our application and ODBC I can see is the #include <sql.h> and <sqlext.h>. However, even those files do not refer to odbccp32.lib (or any other .lib or linker option).
The only references to odbccp32.lib I can find at all are in .obj files. So it appears that VS2010 automagically knows which ODBC libraries to link against based on what functions are referenced in our software (SQLConnect(), for example).
So how might I:
1) "obtain Vista SDK version of odbccp32.lib"?
2) cause VS2010 to link against that version?
-OR-
Is there a better way to solve this?! Right now I am unable to proceed with a conversion of our software from VS2008 -> 2010 unless I can find a way to force this goofy software to compile.
NOTE: Apparently I could force the system to compile using 2008's tooling, which may "cure" this. But that means changing all of our projects up & down the chain to do this, which is rather backwards and contrary to the whole point of moving to 2010, no?
For the curious, the exact linker error:
odbccp32.lib(dllload.obj) : error LNK2019: unresolved external symbol __imp___vsnprintf referenced in function _StringVPrintfWorkerA#20
Reading through your link, it seems that Microsoft has verified that there is a problem, and they intend to fix it in the next version of the SDK. Doesn't help much, does it?
It's quite normal for the linker to daisy-chain through the objects, linking one object only to discover that it has dependencies on other objects. If you want to preemptively link to a specific library, add it to the "Additional Dependencies" in the Linker Input tab of the project properties.
If you aren't able to get the linker to prefer a specific version of a library, just seek out and replace the version of the library in the installation.
I think this is a link to the Vista SDK, but I can't verify it: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ff6467e6-5bba-4bf5-b562-9199be864d29&displaylang=en
I see it. Ouch, my condolences. Their advice is about as best as it is going to get if you don't want to compile with /MD. I think I know the source of the problem, this isn't that easy to fix for them either. It's going to require them getting the VS2010 CRT header file fixed first, then recompile and issue an SDK update. That takes some major doing.
It is getting linked because it is listed in the "Core Windows Libraries" property sheet. View + Property Manager to see it. Not linking it is not an option, you are probably actually using it when you #include <sql.h>
The Vista version indeed doesn't have the same problem, it was probably built with an earlier version of VS. Project + Properties, Linker, Input, Additional Dependencies = "c:\program files\microsoft sdks\windows\v6.0a\lib\odbccp32.lib". This injects the vista version before the 7.0 version. You may have to live with this for a while, be sure to keep VS2008 installed on your build machines.
I just encountered the undefined __imp___vsnprintf symbol while converting an ODBC application to Visual Studio 2015. Figuring that there must be a workaround, I dumped all the symbols exported by the various libraries in the Visual Studio 2015 LIB directories with DUMPBIN and found that this library with a most obvious name, legacy_stdio_definitions.lib, defines these symbols.
Adding this to the LINK command line resolved the missing external referenced by odbccp32.lib.
Once one knows what to search for, some info is available here.
Don't know all the details, so shooting in the dark. When I had a situation when certain functions were available with one compiler and not the other, I created a simple DLL with the functions exported with C interface, using compiler version that supported those functions, and used that DLL with another compiler.
the solution is to link with just odbccp32.lib from v6.0 sdk all else from the default sdk.
1. download v6.0 sdk from: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ff6467e6-5bba-4bf5-b562-9199be864d29&displaylang=en
(do not install documentation and samples/examples, the result is 75MB downlaod):
2. create a folder, some folder.
for example: lib_odbc_fromsdkv6.0 in your project's folder
3. copy the file odbccp32.lib from:
C:\Program Files\Microsoft SDKs\Windows\v6.0\Lib
to folder created above (only one file).
4. in each project's properties add that (lib_odbc_fromsdkv6.0) directory to Library directories:
VC++ Directories -> Library directories
the depended projects in myodbc are myodbc5S and myodbc-installer.
(from Mordachai)
How do you specify, in Visual Studio 2010, the order in which library files should be linked?
I have a project that links against libexpat and against another library. This library (not under my control) seems to also include libexpat. The problem is that 'we' use a different version of the library (XML_UNICODE vs not). In Visual Studio 2008 things seemed to work out okay (might have been a coincidence), but in Visual Studio 2010 the wrong instance of libexpat is linked. I was thinking that if I could specify the order in which these two libraries should be linked that then I could circumvent the problem.
A few years back I discovered a hack that allows you to force Visual C++ to link libraries with a specific precedence. This is not elegant, but it is functional.
It seems that the linker for Visual C++ generates link order on the fly based on symbol dependencies. By adding a symbol reference up-front, you can force the linker to include the first library specified in the linker input. Please note, I have only tested this with Visual C++ 6 and 8 (2005).
Let's say for example that you have two libraries with the symbol XML_ParserCreate:
libexpat.lib - XML_ParserCreate
someother.lib - OtherSymbolsYouNeed, XML_ParserCreate
First, order your library dependencies as you would expect, libexpat.lib and then someother.lib. Via command line these would be options to link.exe. In Visual Studio 2005, they would be options under the project's Configuration Properties -> Linker -> Input -> Additional Dependencies. I would imagine Visual C++ 2010 has a similar menu.
Next, add a command line option that defines a known repeated symbol up-front, by using the /INCLUDE linker option. In Visual Studio 2005, this can be added under the project's Configuration Properties -> Linker -> Command Line -> Additional options:
/out some.exe ... libexpat.lib someother.lib
/include:XML_ParserCreate
The definition of this symbol will cause the linker to immediately prefer the first library that terminates (realizes) it. In general Visual C++ will generate an error with repeated symbols; if you haven't already, make sure you are also specifying the /FORCE:MULTIPLE linker option.
My specific need for this was using the DUMA memory debugging library. It defines a variety of memory functions that are also defined in libcmtd.lib. The following would incorrectly link libcmtd's version of _malloc, despite a library order that seems to the contrary:
/out some.exe ... duma.lib libcmtd.lib
/FORCE:MULTIPLE
This was resolved by manually adding the symbol, and has worked reliably for years:
/out some.exe ... duma.lib libcmtd.lib
/INCLUDE:_malloc /FORCE:MULTIPLE
I have found 'a' solution: if you add the libraries through #pragma comment(lib... the order of linking is the same as the order in which you type those pragma's. I'm still keeping the question open for a solution when the libraries are added through the project file instead of through pragma statements.
You could create a DLL with the third party library and link it against the static version of expat that it needs and then link your code against the version of expat you need.
However, the fact that it worked before might mean that one library has all the functionality of the other plus some extra. I don't know the details of expat. If that is the case, you need to make sure that you only have the version you want to use in your library search path. A different search directory order in the other version of the compiler could explain the change in behaviour.
I think you can change the order in which library files are linked bij adding them in the project file in linker -> input -> additional dependencies. The library files will be linked in the order in which they are specified.