I am trying to compile my Visual C++ project (uses MFC) in Microsoft Visual Studio 2012, and it comes back with the following errors:
error LNK2005: "void * __cdecl operator new(unsigned int)" (??2#YAPAXI#Z) already defined in LIBCMTD.lib(new.obj)
error LNK2005: "void __cdecl operator delete(void *)" (??3#YAXPAX#Z) already defined in LIBCMTD.lib(dbgdel.obj)
error LNK2005: "void __cdecl operator delete[](void *)" (??_V#YAXPAX#Z) already defined in LIBCMTD.lib(delete2.obj)
error LNK1169: one or more multiply defined symbols found
So I googled around a bit and found this page:
http://support.microsoft.com/?scid=kb%3Ben-us%3B148652&x=13&y=8
I tried solution one but the "Ignore Libraries" box does not exist, and so does the Object/library modules box. For the Ignore Libraries I found Ignore specific libraries, but skipping step five only gave me 17xx errors.
I googled around a lot, but always came back to the same page, how can I fix this problem in Visual Studio 2012?
I fixed the problem: I found that it is a problem with the order of the includes. However forcing every file to have the afx.h include (properties->c/c++/advanced/force include file)
fixed the problem for me.
The most likely cause of the problem is having different versions of the C runtime (multi- or single-threaded, debug- or non-debug) linked for different parts of the project. Perhaps your main executable has one runtime linked but you are linking to a library built with a different runtime. Use depends.exe to check each library that you are linking explicitly in turn to find the odd one out.
I also found that if you use LTGC (link-time code generation) and you've just added a custom implementation for operator new or some other symbol that exists in the CRT, then you should do a full rebuild, only then does the incremental linker omit "weak references". This is true even in VS 2015.
Ok, I just dealt with this problem while combining a .c file (compilation unit) with an MFC project. The .c file had the same name (compilation unit) that was in a library I was linking with. I changed the name of the file and the linker confusion went away.
I tried the other solutions above and none of them worked.
Were you having this problem with Visual Studio 2008 or 2010?
I am seeing a similar failure in Visual Studio 2012: code that linked fine in earlier versions of the toolchain is now giving multiple instances of error LNK2005: "void * __cdecl operator new(unsigned __int64,void *)" (??2#YAPEAX_KPEAX#Z) already defined. Unlike you, we're not using MFC.
This is not a solution to your problem, of course, but it may point to a regression bug in Microsoft's compiler or linker development. If you can verify that the same code works fine in VS2010, that would tend to confirm my diagnosis.
(To check this, simply set the Project Properties > Configuration Properties > General > Platform Toolset from "v110" to "v100" for all projects in your solution, and Rebuild All. Assuming you have VS2010 installed on the same machine, you can do this all without leaving VS2012.)
EDITED TO ADD: This error has been reported to Microsoft as bug #768788.
Related
I'm in the process of converting a native C++ Visual Studio 2010 project to Visual Studio 2015 and after fixing a bunch of other stuff I'm finally at the linking stage which is failing with the following error
ucrtd.lib(ucrtbased.dll) : error LNK2005: __crt_debugger_hook already defined in msvcrtd.lib(utility_desktop.obj)
Thinking it may be a C-runtime library mismatch I went back and recompiled all our dependencies using VS2015 and the /MDd switch to control which run-time is used. That didn't fix anything.
According to dumpbin the symbol __crt_debugger_hook is in both libraries, but it only appears in a symbol table in msvcrtd.lib.
There are other executables in my solution that link with ucrtd.lib and msvcrtd.lib yet don't suffer from this problem. The executable that does experience the link failure also links with MFC and BCG, but I don't see how that could be the cause.
Does anyone have any other ideas for what could be causing this problem?
It turns out that the bug isn't in Microsoft's library. Instead it's in the Crypto++ (https://www.cryptopp.com/) library. They forward declare _crt_debugger_hook in a way that is incompatible with changes that were made by Microsoft when they split the c-runtime into ucrtd.lib and msvrtd.lib. The offending line is fipstest.cpp at line 21:
extern "C" {_CRTIMP void __cdecl _CRT_DEBUGGER_HOOK(int);}
the _CRTIMP needs to be removed so that you have
extern "C" {void __cdecl _CRT_DEBUGGER_HOOK(int); }
I've opened a pull request with the Crypto++ folks to fix this (https://github.com/weidai11/cryptopp/pull/151).
After spending some time going back and forth with MS technical support it sounds like this is a bug in VS2015. They couldn't give me any information on when a fix will be available but I can say that it isn't fixed by either update 1 or 2 for VS2015.
I am currently trying to compile and link the CppUTest library with my project. I use CMake to create a Visual Studio 2013 Solution for the CppUTest-library and it builds.
However, when I link the created CppUTest.lib to my application I get an linker error telling me that it can not find multiple symbols like
??0Utest##QAE#XZ)
or
?RunAllTests#CommandLineTestRunner##SAHHPAPAD#Z
Now when I use dumpbin.exe on the lib and option /LINKERMEMBER I get a list of symbols in the library that includes the names
??0Utest##QEAA#XZ
and
?RunAllTests#CommandLineTestRunner##SAHHPEAPEAD#Z
So the names that actually exist are slightly different to the names that my projects expects and I have no idea what causes this problem. Is there any compile option that causes these changes or do I use a different compiler although I think it is the same?
Run the undname.exe utility from the Visual Studio Command Prompt. You get:
Undecoration of :- "??0Utest##QAE#XZ"
is :- "public: __thiscall Utest::Utest(void)"
and
Undecoration of :- "??0Utest##QEAA#XZ"
is :- "public: __cdecl Utest::Utest(void) __ptr64"
Clear enough that this is the default constructor of the Utest class. Note how the calling convention is different, __thiscall vs __cdecl. And how the library version has the __ptr64 attribute.
You see that attribute appear on 64-bit functions. x64 has only one calling convention and does not distinguish between __cdecl and __thiscall.
So it should start to get obvious, the linker wants the first one, the 32-bit version of the constructor. The 64-bit version you supplied can never work since you cannot mix 32-bit and 64-bit code. There should also be a loud warning about that, don't ignore such warnings.
Link to the 32-bit build of this library to fix your problem. Or build the x64 version of your program.
I am adding .dll to C++ project.
IDE: Visual Studio 2013
What I did:
Added directory with headers to VC++ Directories -> Include Directories
. It's ok, I can include headers, IntellySense sees names
in these files.
Added .lib file to Additional Dependencies section and a path to this
file in both VC++ Directories -> Library Directories and Linker -> General -> Additional Library Directories.
Placed actual .dll file to DEBUG folder (also to project folder, just
to be sure)
Used dumpbin.exe to get sure I have exported all needed classes in my
.dll
And I still get a bunch of unresolved externals with functions stored in that .dll. Any suggestions?
I found this question and set Use library Dependency Inputs to Yes. Still no luck.
Some more info:
Error example:
Error 2 error LNK2019: unresolved external symbol "__declspec(dllimport) public: double __thiscall Fem::Node::GetX(void)" (__imp_?GetX#Node#Fem##QAENXZ) referenced in...
This function in dumpbin output:
172 AB 000F81A0 ?GetX#Node#Fem##QEAANXZ
I see some difference in the last part of the name. Somehow, as I mentioned in the comments, I got it working in Qt project with Visual Studio compiler.
This is usually a bad idea, since it doesn't lead to a reusable library. The application can't be rebuilt with a new compiler or even new compile settings without also rebuilding the DLL. It is safer to just compile the classes you use in statically. That said, there are some benefits if used in conjunction with delay-loading, so...
In order to store a class implementation in a DLL, while building the DLL you must use __declspec(dllexport) on the class, and when consuming it there must be __declspec(dllimport). Import libraries have shims to forward free function references to DLLs but those don't work for classes and class members.
Usually macros are used to accomplish the switch between dllexport and dllimport.
Now that you've shown mangled names, the difference becomes apparent, and demangling gives a clue to where the problem came from.
Linker is looking for
public: double __thiscall Fem::Node::GetX(void)
But DLL is exporting
public: double __cdecl Fem::Node::GetX(void) __ptr64
Notice that the calling conventions are different; if this had linked, you would have crashed as soon as you tried to call this function.
You cannot use exports from a DLL that have C++ signatures from an application compiled differently. Are you mixing architectures (x86 vs x86_64 vs ARM)? Can't do that either, not even using highly-compatible C calling signatures.
I'm trying to get around these link errors:
error LNK2001: unresolved external symbol "__declspec(dllimport) public void __thiscall std::basic_ostream(char,struc std::char_traits<char>>::_0sfx(void)"
I used Visual Studio C++ 2010, and tried with Visual Studio C++ 6.0, but still the same errors show up.
The object file is found, so I am suspecting that it cannot find the implementation of the std library? I've tried /nodefaultlib option on a few libraries (libc.lib, libcmt.lib, msvcrt.lib, etc) but did not improve the situation at all.
Could someone explain why the error occurs and where I should look ?
Tried the solutions suggested in other similar questions but they either are not applicable or do not resolve the problem.
Thanks
You should remove /nodefaultlib option.
This problem could arise if some of your libraries are linked static while other dynamically.
Basically if you have both codes compiled with the static version of CRT (that's compiler switch /MT and /MTd) and dynamic version of CRT (switch /MD, /MDd).
You can see what your project is using in Project Properies - c++ - Code Generaion - Runtime Library)
Make sure all your libraries are compiled with the same switch as you project.
When building projects in C++, I've found debugging linking errors to be tricky, especially when picking up other people's code. What strategies do people use for debugging and fixing linking errors?
Not sure what your level of expertise is, but here are the basics.
Below is a linker error from VS 2005 - yes, it's a giant mess if you're not familiar with it.
ByteComparator.obj : error LNK2019: unresolved external symbol "int __cdecl does_not_exist(void)" (?does_not_exist##YAHXZ) referenced in function "void __cdecl TextScan(struct FileTextStats &,char const *,char const *,bool,bool,__int64)" (?TextScan##YAXAAUFileTextStats##PBD1_N2_J#Z)
There are a couple of points to focus on:
"ByteComparator.obj" - Look for a ByteComparator.cpp file, this is the source of the linker problem
"int __cdecl does_not_exist(void)" - This is the symbol it couldn't find, in this case a function named does_not_exist()
At this point, in many cases the fastest way to resolution is to search the code base for this function and find where the implementation is. Once you know where the function is implemented you just have to make sure the two places get linked together.
If you're using VS2005, you would use the "Project Dependencies..." right-click menu. If you're using gcc, you would look in your makefiles for the executable generation step (gcc called with a bunch of .o files) and add the missing .o file.
In a second scenario, you may be missing an "external" dependency, which you don't have code for. The Win32 libraries are often times implemented in static libraries that you have to link to. In this case, go to MSDN or "Microsoft Google" and search for the API. At the bottom of the API description the library name is given. Add this to your project properties "Configuration Properties->Linker->Input->Additional Dependencies" list. For example, the function timeGetTime()'s page on MSDN tells you to use Winmm.lib at the bottom of the page.
One of the common linking errors I've run into is when a function is used differently from how it's defined. If you see such an error you should make sure that every function you use is properly declared in some .h file.
You should also make sure that all the relevant source files are compiled into the same lib file. An error I've run into is when I have two sets of files compiled into two separate libraries, and I cross-call between libraries.
Is there a failure you have in mind?
The C-runtime libraries are often the biggest culprit. Making sure all your projects have the same settings wrt single vs multi-threading and static vs dll.
The MSDN documentation is good for pointing out which lib a particular Win32 API call requires if it comes up as missing.
Other than that it usually comes down to turning on the verbose flag and wading through the output looking for clues.