Does anybody know about this linker error in Visual C++?
PGPkeys.obj : error LNK2001:
unresolved external symbol
_imp_PGPclCloseClientPrefs
Unresolved externals are usually due to missing binary (a DLL or a static lib). Check directory paths to libraries your code needs.
You need to find out in what library/DLL the symbol PGPclCloseClientPrefs is defined.
If mbadawi23's answer doesn't solve your problem, think about the following:
I think imp might indicate an environment mismatch, so make sure you're using the linker that came with VC++ 6. I do not remember VC++6 mangling imported/exported symbol names in that way, but, I could be wrong.
If worst comes to worst, look up making a def file for the DLL in which PGPclCloseClientPrefs lives and export the symbol that way.
Related
I know many people have asked about this error and trust me I've read ALL of them and followed all the steps! But I'm still getting the unresolved external symbol error.
I'm trying to use the dll of lp_solve (a linear programming package) in my c++ code in visual studio 2012.
The error message I'm getting is:
Error 80 error LNK2019: unresolved external symbol _make_lp#8 referenced in function "void __cdecl my_solve(BLAH BLAH)
The function make_lp() is from the lp_solve package and I'm calling it from my_solve() in my code. This error message pops up for each solver function I call. Seems the linker just couldn't find any of the implementation of these functions.
I've done the following
put #include "lp_lib.h" in my source code
put the .dll, .h and .lib files from the lp_solve package in the working directory and
added the path under Linker:General:Additional Library Directories.
added the lib under Linker:Input:Additional dependency
What's wrong?
Thanks for your help!
The problem I had was solved after realizing I downloaded the WIN64 package for lp_solve but my visual studio is using WIN32 as build platform (even though my machine is x86_64).
Using extern "C" may be helpful while including lp_lib.h in your .cpp as follows:
extern "C"
{
#include "lp_lib.h"
}
For more information, please check this link:
http://www.geeksforgeeks.org/extern-c-in-c/
For a research project, I'm writing a C++ add-on to a scientific computing language. Unfortunately the library that allows users to do this is not kept very well up-to-date.
I started the project in XCode, where it built fine. Later I had to move to a PC, so I migrated the code to Visual Studio 2015. Since doing this, I haven't been able to build due to the following errors:
LNK2001 : unresolved external symbol _sprintf
LNK2019 : unresolved external symbol _sscanf referenced in function _GetDDouble
LNK2019 : unresolved external symbol _sprintf referenced in function _CheckRunningInMainThread
An attempted fix was to add the header #define _CRT_SECURE_NO_WARNINGS. However, this a) fixed no errors and b) added the warning C4005 : '_CRT_SECURE_NO_WARNINGS': macro redefinition. I assume the library already defined this macro, anticipating this problem. Regardless, it didn't solve the problem.
How should I proceed?
Add the following library to the linker input files:
legacy_stdio_definitions.lib
VS 2015 now uses inline definitions that call internal functions for many of the stdio.h functions. If an object file (or library member) depends on one of those functions, then the legacy_stdio_definitions.lib provides an externally linkable version of the function that can be linked to.
Your other option is to recompile the unit that depends on those functions with VS 2015 (this is probably the preferred option).
I got this error compiling cycling max plugins against version 5 max sdk (pure c api). The legacy library fix didn't work for me (it should have, and if anyone had any idea why it mightn't I'd be curious), but I defined _NO_CRT_STDIO_INLINE before stdio was loaded and that did do the trick.
I recently encountered this and was able to add User32.lib to Linker > Input > Additional Dependencies.
You could also include #pragma comment (lib, "User32.lib") in your code.
I frequently have this problem when I try a new library. This time I work with PointGrey Camera and try to use its API libraries (some dll, lib, header files). Mostly, problems were fixed by configuring the SDK (I'm using VS2008) Tools/Options/VC++ Directories/include files(/library files)(/executable files),
I also tried with project configuration:
+ project properties/linker/input/additional dependencies
+ project properties/linker/General/Additional Library Directories
This time, with all this, I still have the error.
Is there a general method to deal with this problem?
do I need to understand this diagnosis from VS2008?
Error 1 error LNK2019: unresolved external symbol __imp__flycaptureGetPacketInfo referenced in function "enum FlyCaptureError __cdecl initializeStandardEventSizes(void *,struct FlyCaptureImageEvent * const)" (?initializeStandardEventSizes##YA?AW4FlyCaptureError##PAXQAUFlyCaptureImageEvent###Z) main_2.obj test
does using analysis tool such as Dependencies Walker ensure to solve these problems well??
This message says that you used a symbol (a function or a variable) in your code. This symbol was probably declared somewhere (most likely in a header file you included in your code) otherwise there would have been a compilation error. When the linker searched for the symbol (in both your object files and the lib files you instructed it to look in) it couldn't find it.
That usually happens because you forgot to let the linker know about a lib you want it to search in.
Most libraries come with a set of instruction that is supposed to help you set up everything correctly and avoid running into these problems.
This problem has been solved lately. I installed the incompatible library of PointGrey. That's why it didn't work. But this says something between "incompatible library" and "unresolved exertal symbol error"
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.
Link errors like this sometimes occur when compiling C++ using Microsoft Visual C++ 6.0:
error LNK2001: unresolved external symbol __imp__close
error LNK2001: unresolved external symbol __imp__read
error LNK2001: unresolved external symbol __imp__lseek
error LNK2001: unresolved external symbol __imp__open
My fix, which I found after searching fruitlessly using Google for a long time, is this:
Do NOT disable language extensions. In the Project Settings dialog, in the C/C++ tab, make sure that the 'Disable language extensions' checkbox is not checked.
The functions close, read, lseek, open, etc., are not standard parts of the C library and the declarations are skipped by conditional compilation using #if !__STDC__ in <io.h>. This happens if you disable language extensions.
The answer is that the __imp prefix refers to function stubs in the OBJ library for the DLL version of the CRT. This means your linker options are incompatible with your compiler options (linker set to static CRT or no CRT and compiler set to dynamic CRT).
In your case rather than the CRT itself it is another library, but the same idea.