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.
Related
I am implementing a SLAM-algorithm in Visual Studio 2019 where I want to use the ICP algorithm from the MRPT library for scan-matching.
I installed the MRPT library as 32-bit from source code using CMake. Problem is the error I'm receiving when building the solution (shown below). I assume it is because I have not added Additional Library Directories or Additional Dependencies for the Linker, because I can't find the .lib/.dll files anywhere. I tried installing the 64-bit precompiled binaries for Windows, where I found the .lib-files inside a lib-folder which does not appear when compiling manually with the source code - but can't use the same lib's because I need 32-bit (I tried linking to them, but the same error occurred in addition a bunch of warnings that library is 64-bit and target is 32-bit).
The code is pretty much exactly the same as the first example here, with (I believe) all necessary headers included.
The error produced (I also receive many more of the same error for every class I attempt to use from the library):
particle.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall mrpt::poses::CPose2D::CPose2D(double,double,double)" (__imp_??0CPose2D#poses#mrpt##QAE#NNN#Z) referenced in function (function)
The quick question is: Shouldn't the .lib/.dll files be produced when compiling from source code as well? Or is there something embedded in the library so I don't need them, in which case there must be something else wrong?
The more complicated question is: If the missing .dll/.lib-files is not the problem, what could it be?
Sorry if I am missing any relevant information, this is my first post. Just let me know and I will provide.
Any help is greatly appreciated!
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 have a problem writing wrapper program to use vendor's library in .Net client program(C#).
What the vendor provided are C++ header file and MFC static library file(.lib) built on both release and debug.
The problem is, when I build wrapper program, Visual Studio 2012 spits LNK error out like this:
error LNK2001: unresolved external symbol ___argc nafxcwd.lib(appcore.obj)
error LNK2001: unresolved external symbol ___argv nafxcwd.lib(appcore.obj)
I set up build property with option /clr,
set runtime library as Multi-threaded debug DLL (/MDd),
set using MFC as MFC in shared DLL,
ignored libraries(nafxcwd.lib;msvcrtd.lib;msvcmrtd.lib;libc.lib;libcmt.lib;msvcrt.lib;libcd.lib;libcmtd.lib, see this),
added dependencies(nafxcwd.lib;msvcrtd.lib;msvcmrtd.lib;(vendor's library), for CRT, MFC library order).
What I missed?
I don't know I described enough. If something is ambiguous, please ask to me.
Thanks in advance!
ps. I'm very new to C++(even Visual Studio..). I'm more familiar with Java.
I get the following error while trying to build a CUDA/C++ code in Visual Studio 2012. I'm using CUDA v5.0
1> Generating Code...
1>LINK : warning LNK4044: unrecognized option '/MLd'; ignored
1>cublas_device.lib(kepler_sm35_gemm_wrapper.obj) : error LNK2019: unresolved external symbol __cudaRegisterLinkedBinary_59_tmpxft_00001040_00000000_8_kepler_sm35_gemm_wrapper_cpp1_ii_9402ff4f referenced in function "void __cdecl __sti____cudaRegisterAll_59_tmpxft_00001040_00000000_8_kepler_sm35_gemm_wrapper_cpp1_ii_9402ff4f(void)" (?__sti____cudaRegisterAll_59_tmpxft_00001040_00000000_8_kepler_sm35_gemm_wrapper_cpp1_ii_9402ff4f##YAXXZ)
Anybody has any idea of where the problem might be? I've tried googling around, but haven't found a solution for this as yet.
Thanks a lot!
This article shows information about what the /MLd linker option does. It essentially has to do with multithreaded libs being loaded and the configuration of your project.
Is your (Debug) project set up to link with the microsoft linker or nvcc? (The error messages appear to be coming from the microsoft linker.) You may want to look at this question
Device code and device libraries (that you are linking against) need to be linked with nvcc.
You need to link against the debug version of the CUDA library. You try to compile in Debug mode, but then you link against a library which seems not to have been built in debug mode. Thus it gets all messed up.
So you should either get the .lib file for the debug version, or build it yourself if you have the source code. Then you link your debug build with the debug .lib and same for release.
Also, it may help that you use the same version of the compiler to build all libs, otherwise you may run into name mangling issues (which could be also a potential cause for your problem). It happened to me after switching to a newer VS version: I had to recompile all the .lib I was linking against.
It looks like some sort of using a external (extern) variable that isn't defined. The code is required for further information
I was able to fix it! I was linking to cublas_device.lib which was referring to an unresolved external symbol. However, this lib file wasn't required by my project, so just removing it from the linked files worked! However, in Release mode this error wasn't happening - maybe because this part of the code in cublas_device.lib was in the debug section.
In any case, since it is not required by my project, removing it solves the problem.
Thanks a lot for all your replies!
I encountered the same issue, Changing the Configuration Type from "Dynamic library (dll)" to "Static library (lib)" worked for me.
I have a question about how constants defined in math.h are linked.
In visual studio 2010, I'm building a 64-bit dll c++ library with "MD" that uses a third party library that make use of "HUGE_VAL". From the header "math.h", it seems that "HUGE_VAL" is defined as "_HUGE". When I try to build, a linking error results
error LNK2001: unresolved external symbol _HUGE
After doing some googling, I think _HUGE should be defined in msvcrt.lib. MSVCRT.lib is linked, but I didn't link libcmt.lib because it would cause re-definition errors.
What strikes me as odd is that when I create a simple console program that uses HUGE_VAL and use /verbose as a linker option, it shows _IMP_HUGE being linked.
What I'm really curious of is at what stage does _HUGE turn into _IMP_HUGE? Also, have anyone else gotten the unresolved _HUGE error and does anyone have any ideas for how it could be fixed?
Thanks for reading the long question and for any ideas.
I have experienced this issue with VC11.0. The only error I get is an unresolved symbol _HUGE error.
I am linking with dynamic multi-threaded run time libraries and I found that if I were to include "libcmt.lib" in my link step, then the issue is resolved (or worked around).
I started looking into how the headers were defined in the SDK for clues and found that I was missing a compiler pre-directory in my compile steps: _DLL.
When you build with dynamic run time libraries the _HUGE variable needs to be __declspec(dllimport) so it can be found. When you include "math.h" -> "crtdefs.h" without setting _DLL as a pre-directive, the variable will not be __declspec(dllimport)'ed and will appear missing at link time.
I was getting this issue because I am compiling with my own custom makefiles and I had neglected to add the _DLL pre-directive. Adding -D_DLL to my compilation step resolved the compile issue with no other changes needed.
I know this thread is old, but figured I would throw it out there as it may help someone with a similar issue.