I've built a C++ Windows dll using Visual Studio - a.dll.
I used Cygwin and MinGW (x86_64-w64-mingw32-gcc) to build a helper C library - helper.lib.
The dll needs to use the helper library, so I modified Visual Studio project, tried to link with the library, but I get:
error LNK2019: unresolved external symbol __mingw_vsnprintf referenced in function inquiry where inquiry is one of the functions inside helper.lib.
What am I doing wrong?
Related
The title basically covers it.
The DLLs seem to be linked fine in the Linker property pages settings, based on that fact that they link without issue when using the 32-bit build platform.
I have looked into the two LNK errors online but haven't found anything that's been able to address the problem specifically.
Has anyone seen this before, or does anyone have thoughts on how to approach this?
Here are a couple of examples of the errors:
Error
LNK2001
unresolved external symbol "public: class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > > __cdecl CUserContext::GetUserDisplayName(void)" (?GetUserDisplayName#CUserContext##QEAA?AV?$CStringT#DV?$StrTraitMFC_DLL#DV?$ChTraitsCRT#D#ATL#####ATL##XZ)
ApplicationIMPLDLL
Error
LNK2019
unresolved external symbol "public: int __cdecl CDBManager::IsOpen(void)" (?IsOpen#CDBManager##QEAAHXZ) referenced in function "public: __cdecl CApplicationIMPLManager::CApplicationIMPLManager(class CDBManager *)" (??0CApplicationIMPLManager##QEAA#PEAVCDBManager###Z)
ApplicationIMPLDLL
According to Microsoft Docs, there is one cause of lnk2019 and lnk2001:
You attempt to link 64-bit libraries to 32-bit code, or 32-bit libraries to 64-bit code
Libraries and object files linked to your code must be compiled for
the same architecture as your code. Make sure the libraries your
project references are compiled for the same architecture as your
project. Make sure the /LIBPATH or Additional Library Directories
property points to libraries built for the correct architecture.
based on that fact that they link without issue when using the 32-bit build platform This sentence seems to indicate that your dll is 32-bit. If so, Windows can not load a 32-bit dll into a 64-bit process.
If you have the source code of these dlls, you could compile them into 64-bit.
Of course, there is also a way to load 32-bit dll into 64-bit program. You could refer to this link for more details.
I am trying to compile networking dll project in Visual Studio 2010. In past, the original authors used the project to produce standalone dll file that could be distributed with the server it was used for. If I open their dll, I cans see this in dependency walker (the red items are not really an issue, the dll works):
Now I tried to compile the project, but for both 32bit and 64bit (and 64bit is what I'm supposed to get to work) I produce a library that requires OpenSSL installed:
Trying to put the libeay32.lib out of the build just causes link errors:
1> Finished searching libraries
1>TTClient.obj : error LNK2001: unresolved external symbol _BF_set_key
1>TTProtocol.obj : error LNK2001: unresolved external symbol _BF_ecb_encrypt
1>D:\techsys\WebSightR220lib\Release\WebSightR220lib.dll : fatal error LNK1120: 2 unresolved externals
Turns out linking seemingly huge static library is not as big problem when you want to use just a fraction of OpenSSH. The compiler will not just copy the library in your binary, it will just pick the parts that are needed.
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 just switched to Octave from Matlab and would like to continue to compile mex-files as a DLL through visual studio.
I have a project which creates a dll and exports the mexFunction as previously. I also include the mex.h file found in Octave but I have trouble linking.
Currently I get a linking error stating:
error LNK2019: unresolved external symbol __imp_mexPrintf referenced in function mexFunction
I understand why but I don't know what to include to resolve this issue.
Can anybody help?
Thanks
Henrik
The files are found in:
C:\Octave\Octave-3.8.2\lib\octave\3.8.2
and I used liboctave.dll.a and liboctinterp.dll.a
i have compiled c++ files and make it as a lib using cygwin in windows. when i try to use that lib in visual studio 2005 c++. it produces the following errors.
"Error 1 error LNK2001: unresolved external symbol ___gxx_personality_v0 mylib.lib
Error 2 error LNK2019: unresolved external symbol __Unwind_Resume referenced in function _fjfx_create_fmd_from_raw mylib.lib
Error 3 error LNK2019: unresolved external symbol ___chkstk referenced in function __fjjj mylib.lib"
how to resolve it.
Yes, you need to build your library using the visual studio tools. The "gxx_personality_v0" is a symbol created by the g++ compiler, and can only be resolved by linking with the relevant libstdg++ library. Same for the other components.
Unfortunately, some parts of the runtime support for one compiler doesn't match when using a different compiler.
You could possibly get away with it if you link your Visual Studio code with the relevant GNU libraries, but I'm far from convinced.
[And I fully expect you to explain that the reason you compiled using cygwin is that the code contains a bunch of stuff that can't be compiled with Visual Studio because it uses gnu compiler extension features...]