This question already has answers here:
What is an undefined reference/unresolved external symbol error and how do I fix it?
(39 answers)
Closed 5 years ago.
I have inherited a legacy project which utilizes some external functions from a *.lib. From what I was told, the syntax for using the *.lib was correct and this
was buildable in whatever visual studio version they used. (ie, there is an extern "C" prototype file, and all the function signatures are correct).
When building, I get "error LNK2019: unresolved external symbol _A86_ReadConfigReg#12 referenced in function ..."
I'm pretty confident that this is related to the *.lib file since the *.lib file has "A86" in the name...There is also a *.dll with the same name.
I went to project properties -> Linker -> Input and listed the *.lib file name in "Additional Dependencies", but no luck. I tried adding the include directories, copying the *.lib & *.dll to the executable location. But no luck.
How do I go about fixing this error?
First thing you should do is inspect the library to make sure the referenced function is there. Start an msvc developer command prompt, and run dumpbin.exe
Syntax:
dumpbin /exports <full path library name>
This will give you a listing of all exported symbols from the library.
You'll get a clearer idea of what to do from there.
[EDIT]
dumpbin told you that your lib exports a function called A86_ReadConfigReg, which is a __cdecl signature and not a __stdcall signature like _A86_ReadConfigReg#12 that your linker expects.... At least two things you should do/check in order of priority.
Your linker is looking for a pascal call signature and this is very odd. Does your project have __stdcall as a default for function calls? That's controlled by the /Gz switch in Project Properties->C/C++->Advanced->Calling Convention. Default should be set to __cdecl (/Gd)
You should check that your include files enclose all the function declarations in an extern "C" { } block. If they don't, you can place the block around the #include directive, so you do not have to modify the library's files.
Like so:
extern "C" {
#include <mylib.h>
}
Related
I am trying to build Lua and QtLua with MSVC 2015 x86 and I have encountered an issue with exported/imported symbols.
Here is what I do forbuilding Lua 5.3.2 (source):
cl /MD /O2 /c /DLUA_BUILD_AS_DLL *.c
ren lua.obj lua.o
ren luac.obj luac.o
link /DLL /IMPLIB:lua5.3.2.lib /OUT:lua5.3.2.dll *.obj
link /OUT:lua.exe lua.o lua5.3.2.lib
lib /OUT:lua5.3.2-static.lib *.obj
link /OUT:luac.exe luac.o lua5.3.2-static.lib
So far it works and dependancy walker shows that functions are exported without any mangling.
Then I build QtLua using cmake and I'v got about 100 errors like:
error LNK2019: unresolved external symbol _lua_close referenced in function "public: virtual __thiscall QtLua::State::~State(void)" (??1State#QtLua##UAE#XZ)
So basically my issue is that the DLL exports lua_close and the linker looks for _lua_close.
After a bit of searching the _lua_close format seems legit as Microsoft documentation states that C symbols called with __cdecl are mangled with a '_' prefix.
However I don't get why the DLL exports unmangled names.
Function declaration when compiled in Lua (C files)
__declspec(dllexport) void (lua_close) (lua_State *L);
Function declaration when compiled in QtLua (C++ files)
extern "C" {
extern void (lua_close) (lua_State *L);
}
Quick answer
MSVC did not found the lua DLL (or lib).
Long answer
Exported C functions called using __cdecl are not mangled, whereas internal C functions called using __cdecl are mangled with a '_' prefix.
Source: http://wyw.dcweb.cn/stdcall.htm
To fix my issue I took all source files from QtLua and created a qmake project from them. And tadaa! It works! (Well, it doesn't because QtLua doesn't seem to be tested on anything else than gcc, but I got rid of this linker problem).
My conclusion is that:
MSVC complains about not finding _function and is in fact looking for function (or maybe both).
CMake, even if it found the lua library at config time, failed to pass the proper options to the linker at build time.
There is a project made in C, its file is RawInput.c from http://www.codeproject.com/Articles/185522/Using-the-Raw-Input-API-to-Process-Joystick-Input. I have compiled it and it works perfect in vs2012. But when i pasted the same code within a cpp of a a new project i get 4 of these errors, just different decleration names.
error LNK2019: unresolved external symbol "long __stdcall HidP_GetCaps(struct _HIDP_PREPARSED_DATA ....
fatal error LNK1120: 4 unresolved externals
i guess it has something todo with me trying to run c code within a c++ compiler without telling it the right way. Perhaps there must be extern "C" somewhere? I wouldnt know even tho i tryed my best to search the webb for solutions. Help would be appreciated. Thank you.
It seems that Hidsdh.h is not a C++ compatible header. Include it like this:
//This is not a C++ header
extern "C"
{
#include <Hidsdi.h>
}
You probably need to add the library file hidparse.lib, which contains the HidP_GetCaps function. Right-click the project in the solution explorer, select Properties, and under the Linker section (Input) add hidparse.lib to the 'Additional Dependencies'.
Adds library paths for project properties as following.
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17134.0\um\x64
Add a library "hid.lib" file.
Help me guys,
I've been searching for a really long time.
I'm using visual studio 2010 and I tried to include an external lib but I get an unresolved external error.
The external project is composed of files in the following way
backend.cpp
//some functions
frontend.cpp
//some functions
header.h
I build this project using SCons then I includes the .lib file in the project and refered to its path and I copied the .h file to msvc directory .
VS seems to access and read the functions in backend.cpp(from the auto complete) but when I run the project it says that there is an unresolved external # the called function
I'm not a Visual Studio expert, but I guess that it being able to auto complete your code is associated with it finding the headers of your source code.
Unresolved external means that the compiler can't find the object files in the linking process. This could mean that you failed to add the lib files correctly, or that you are missing some .cpp file.
That may happen for a variety of reasons. But all of them end up being one of the following:
You are not linking the correct .lib file.
The symbol name you are using in your program is not identical to the one provided in the .lib.
The first one is easy enough to check, so please, double check it.
The second one is trickier. The symbol name used in your program is output in the error message "unresolved external symbol abc", or whatever. The symbols available in the library can be listed with the command: dumpbin /all name.lib.
If you cannot find the problem, please post the exact error you are getting and the output of the dumpbin program.
I get this error in visual studio and I don't know the reason. It doesn't even show the line number. Any clue?
Error 1 error LNK2028: unresolved
token (0A000041) "void __cdecl
free_img(struct Image *)"
(?free_img##$$FYAXPAUImage###Z)
referenced in function "double *
__cdecl calc_zernike_moments(struct Image const *,int,struct ZernikeBasis
const *)"
(?calc_zernike_moments##$$FYAPANPBUImage##HPBUZernikeBasis###Z) zernike_moments.obj TestLibrary
You have a routine
double * __cdecl calc_zernike_moments(struct Image const *foo,
int baz,
struct ZernikeBasis const *bar)
that calls a routine
void __cdecl free_img(struct Image *foo)
and you didn't supply the free_img() routine that matched to the linker.
free_img() is a function that is either defined in a .cpp file that you haven't included in the project, or it is in a DLL or static library that you haven't linked against. If it is the former, you need to search for the function in your source files and then add that .cpp file to the project. If it is the latter, then you need to identify which library provides free_img() and then locate the .lib file for that library. Then you can do this:
To add .lib files as linker input in the development environment
Open the project's Property Pages dialog box. For details, see Setting Visual C++ Project Properties.
Click the Linker folder.
Click the Input property page.
Modify the Additional Dependencies property.
(from http://msdn.microsoft.com/en-us/library/ba1z7822(VS.80).aspx)
You need to link the library. Where is the definition of free_img()?
You are just including the .h and not linking lib
The error is a linker error, not a compiler error, so there won't be a line number associated with it. Rather the error is telling you that your function calc_zernike_moments is calling another routine, free_img, that isn't defined in any of TestLibrary's compiled sources, so you need to provide it by other means. Typically what's missing here is the third-party library need be included in the project so the linker can bring in free_img's implementation.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is an undefined reference/unresolved external symbol error and how do I fix it?
I am working on wrapping a large number of .h and .lib files from native C++ to Managed C++ for eventual use as a referenced .dll in C#.
I have the .lib files linked in and everything has been going smoothly so far. Upon wrapping the latest .h file, I hit a snag when 2 functions came back with the link error:
error LNK2019: unresolved external symbol __imp__htonl#4 referenced in function
"public: void __thiscall Field::setCharacter(unsigned char,int)"
(?setCharacter#Field##QAEXEH#Z) myutils.lib
I have referenced myutils.lib in the linker options, so that shouldn't be the issue.
What's strange is that I have about 20 functions in this particular .h file and all of the rest are linking just fine except for 3 functions.
Any ideas?
The missing symbol is __imp__htonl#4, which is a C++ mangled name for htonl, which is a function that converts a long value from host to network order. The #4 is used to mangle the input parameters and is part of C++ support for overloaded functions to allow the linker to resolve the right function w/o name collisions.
Make sure that you are linked to the network library that you are referencing this symbol from. Presumably your package is using some special definition of this symbol, instead of the MACRO that it usually is.
Are you sure the signatures match? Be sure to checked for signed-ness and const-ness. Also, make sure functions aren't inlined.
I ran into this error when I compiled against a library and then changed the library before linking. Make sure your headers are the same ones provided by your library (not copied from another architecture, etc). Of course, make sure you're linking against ws2_32.lib (-lws2_32 for mingw/gcc).
Additionally, if you are using GCC/mingw you may want to take a look at this: MinGW linker error: winsock