I'm in the process of porting one of my project to an existing framework I've been developing. As a result I have two project, one that's the original I developed and then the ported one.
The problem I'm having is that the new project doesn't link. The error is "... unresolved external symbol ..." where the symbols should be defined in a library that's linked together with the project. By using VS command line tool dumpbin.exe I confirmed that the symbols said to be missing are in the library. The original project works fine, only by removing the library from the Linker->Input->Additional Dependencies do I get the same errors for that project.
Are there other reasons for "... unresolved external symbol ..." or am I simply not linking the library?
Details
The library in question is OpenCL.lib and the errors are "error LNK2019: unresolved external symbol _clBuildProgram#24 referenced in function ..." for all OpenCL API calls. Using the technique described in Tools for inspecting .lib files? I get the symbols for each function as one would expect.
Okay, figured it out. The library I'm linking with is only for x64 architectures, switching to that platform got it working.
Would've liked a more descriptive error from VS but what can you do...
Related
I'm trying to move a project from LabWindows/CVI 9 to Visual studio, I've been correcting errors by importing cvi libraries, now I've run into this error, but I can't find where the library comes from and it seems to be the last one I'm missing
LNK2019 unresolved external symbol _main referenced in function _WinMain#16 MES_Control_2.0.3.39 cviwmain.lib(extwmain.obj)
in the case of the other libraries it gave the same error but now I can't find extwmain.c or extwmain.lib
Your project already is configured to link cviwmain.lib. The error means it needs a main() function. You probably configured your project as a windows application(not a console application), so just remove that library because you don't need it. See this documentation for detail.
I'm developing a VoIP application (C++/CX) targeting the Universal Windows Platform. At some point, the app needs to query an LDAP server who is keeping a phonebook directory.
As I couldn't find an equivalent of the System.DirectoryServices framework for the UWP, I tried to compile the libraries myself with no success so far. The thing is every OpenLDAP doc on how to build the project for Windows seems to be really outdated. But looking into the sources, I see they provide sample solutions up until Visual Studio vc15, so it is definitely not abandoned.
I tried to build both projects (lber and ldap) and run into many dependency problems. I needed to build Cyrus SASL libraries and OpenSSL, then put all the include paths into the project and link the enerated library objects until I successfully got both libs (olber32_a_debug.lib & oldap32_a_debug.lib) to build.
Finally, I tried to include them into my app project. Still running into some linker issues regarding cyrus.
Linker Issues LNK2019
unresolved external symbol __imp__sasl_version referenced in function _ldap_int_sasl_init [oldap32_a_debug.lib(cyrus.obj)]
unresolved external symbol __imp__sasl_dispose referenced in function _ldap_int_sasl_close [oldap32_a_debug.lib(cyrus.obj)]
unresolved external symbol __imp__sasl_errstring referenced in function _ldap_int_sasl_bind [oldap32_a_debug.lib(cyrus.obj)]
So my question is, have someone compiled OpenLDAP libraries for UWP succesfully? Is there a more recent documentation on how to do so that I'm missing? Any hint/advice on the topic will be greatly appreciated. Many thanks.
I am trying to use a library compiled with mingw in visual studio. However, I get the following linker errors:
error LNK2001: unresolved external symbol __imp___iob
error LNK2019: unresolved external symbol __imp___pctype referenced in function
error LNK2019: unresolved external symbol __imp____mb_cur_max referenced in function
error LNK2001: unresolved external symbol _fprintf
I was able to fix the _fprintf error by linking against legacy_stdio_definitions.lib as per this post : unresolved external symbol __imp__fprintf and __imp____iob_func, SDL2.
However, I have no idea how to fix the other three unresolved externals. How can I fix this? The libraries work perfectly under Visual Studio 2013.
Edit:
Okay here is an update. I moved libmsvcrt.a from the mingw lib folder into Visual Studio, and I added that to the linker settings. Now it seems to work correctly.
The libraries were compiled against an old version of the CRT. The unresolved symbols you get are internal symbols of the CRT that are present in the compiled library. You have to recompile the library against the VS2015 CRT (the Universal CRT). But I'm not sure if MinGW supports this.
If you can't do that, you have to continue to use the VS2013 compiler. (You can use the VS2015 IDE, by setting the toolset to vs2013 in the project options. But you'll still be limited to the C++ features the 2013 compiler supports.)
I encountered the same problem (library compiled with static CRT instead of CRT in DLL) and I managed to make it work by changing the two following parameters in Project Properties:
Linker > Input > Ignore specific default libraries: libc.lib
C/C++ > Code Generation > Runtime Library: Multi-threaded Debug (/MTd)
If that's not enough, there's more at following page: https://social.msdn.microsoft.com/Forums/en-US/841e5723-bce4-4340-b7b3-027dcdf90f00/
I'm trying to get some OGRE sample to compile in VS 2013 but I keep getting the same error no matter what I do:
error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)"
The OGRE SDK comes with the boost library. Unfortunatly it is not compatible with VS2013 so I've downloaded the last version compiled using VS2013. You can find it here
The "additional Include Directories" and "additional Library Directories" are properly setup.
The error state that you are using a symbol that is declared, but not implemented, boost::system::error_category is a method of boost, that various libraries use when managing errors, it belong to the system library, the implementation of this method is in [BOOST_ROOT]\boost\libs\system\src\error_code.cpp.
The most probably cause is that your are including the OGRE's library or part of the library that include some boost's libraries that use this method.
A lot of libraries from boost are header only, but this specific library system are not, it need compilation of this .cpp: two possible fixes are compiling an .LIB or .DLL from boost (see Prepare to Use a Boost Library Binary for more info about this) and using this in your project (could be better if you would be using a lot of libraries from boost that are not header only) or the most easy fix: including the error_code.cpp file in your project and compiling again.
I've been trying to get to get a basic v8 program working under visual studio 2010. I've been able to build v8.lib and v8.dll with no problems. I placed the .v8.dll in my debug folder, and added the v8.lib to VC lib folder.
I added v8.lib to my list of additional dependencies, but when I try and build anything using v8 code, I get a series of "error LNK2001: unresolved external symbol" errors such as "Error 13 error LNK2001: unresolved external symbol _imp_EncodePointer#4 C:\KHMP\Game_Cpp\KHMPCpp\KHMPCpp\MSVCRTD.lib(atonexit.obj)"
I'm not sure what library I'm missing. V8 is definitely being linked as if I remove it from Additional Dependencies, the number of errors increases. I found something about needing to use ws2_32.lib, but including that in with my additional dependencies did not fix the problem.
Does anyone have any idea what libraries I might be missing/what I might be doing wrong?
You are missing the kernel32.lib dependency. Getting it from a file named MSVCRTD.lib is very fishy, that's the import library for the CRT. Do make sure that whatever 'framework' you are using isn't trying to replace it. And make very sure that you haven't been copying .lib files to try to solve another linker problem. Like copying libcmtd.lib to msvcrtd.lib, that's guaranteed runtime trouble too.