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.
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.
So this is a common error but all the posts say I need to pay more attention to which versions of libraries I'm including. I'm using SDL2, OpenGL, and SDL_Mixer... I don't have any options in what I include except to stick with 32-bit libs.
Debug compiles fine but release gives me the LNK2005 error unless I set runtime libraries to /MD. I'd like to avoid that extra dependency. The resulting executable stops responding on SDL initializations or some OpenGL calls unless Visual Studio launches the release build. So I've got some kind of multi-threading issue but I'm not close to understanding it. Little help?
UPDATE: /FORCE:MULTIPLE allows the project to be compiled with /MT. But just like with /MD, the resulting executable crashes unless visual studio launches the release build. What does that mean?
UPDATE2: Use /MD in SDL projects. Crash was just a memory error the debugger wasn't catching. Linking was unrelated.
Ok, so your only other options I see are
(1) ignoring the other library that is causing the LNK2005 error (since you are defining something in two places, it doesn't know which one to use. Since ignoring libcmt.lib caused a lot of issues, maybe try the other place that defines the method).
2) Use /FORCE:MULTIPLE in your linker command line options, which will have it allow multiple definitions of a symbol.
Is rebuilding SDL an option? If so
get the source from libsdl.org
go to the VisualC directory
select the relevant solution
from there, for each of the projects, change the build type from /MD to /MT
rebuild: you should now just get a lib and DLL which are built as /MT and should link with your program compiled as /MT. You should no longer have to resort to /ignorelibs and /forcemultiple
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.
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.