Error lkn: 2019 .. External commands that cannot be parsed ..........

External symbol "symbol" that cannot be parsed by lnk2001
Possible causes

The content requested by the Code does not exist (for example, the characters are misspelled or case-insensitive ).
The content of the Code request is incorrect (a mixed version library is used. Some libraries come from one version of the product, while others come from another version ).
This error message is followed by the fatal lnk1120 error.

Reason

Code Problems

If lnk2001 diagnostic text report _ check_common1_ageruntime_version is an external symbol that cannot be parsed, refer to lnk2019 to learn how to solve this problem.
The member template definition is out of the class range. One restriction of Visual C ++ is that the definition of the member template must be completely within the Closed class. For more information about lnk2001 and member templates, see the Knowledge Base Article q239436.
Lnk2001 is caused by case mismatch in the code or module definition (. Def) file. For example, if you name a variable var1 in a C ++ source file and try to access the variable with var1 in another source file.
If the project uses function inline, but the function is defined in the. cpp file rather than the header file, lnk2001 will occur.
Calling a C function from a C ++ program without using extern "C" (which causes the compiler to use the C naming convention) causes lnk2001. The compiler options/TP and/TC enable the compiler to compile files into C or C ++ respectively, regardless of the file extension. These options make the function name different from your expected name.
An attempt to reference a function or data without external links will cause lnk2001. In C ++, inline functions and const data have internal links unless explicitly specified as extern.
If the function body or variable is missing, lnk2001 may occur. If only the function prototype or extern Declaration is available, the compiler continues to run without any errors. However, because the function code or variable space is not retained, the linker cannot resolve the address call or variable reference.
Lnk2001 is triggered when a function that does not match the parameter type in the function declaration is called. Name modifier combines function parameters into the final modifier function name.
The prototype contained in the error causes the compiler to not provide the function body, which causes lnk2001. If both class implementation and non-class implementation of function f are available, pay attention to the C ++ range parsing rules.
When C ++ is used, the function prototype is included in the class definition but not included in the implementation (the implementation of this class) will cause lnk2001.
An attempt to call a pure virtual function from the constructor or destructor of the abstract base class will result in lnk2001. Pure virtual functions are not implemented by the Base class.
An attempt to access the static variable from outside the file containing the static variable declaration results in lnk2001. According to the definition, the function declared with the static modifier has a file range. Static variables have the same restrictions.
An attempt to use a variable declared by the function outside the function scope (local variable) will cause lnk2001.
An attempt to use the global constant of c ++ in multiple files will result in lnk2001. Unlike C, the global constant in C ++ has a static link. To avoid this restriction, You can include const initialization in the header file and include this header in. in the CPP file, you can also make the variable into a very number, and then use constant reference to access it.
When a release version of the ATL Project is generated, it indicates that the CRT startup code is required. To fix the issue, Perform one of the following operations:
Remove _ atl_min_crt from the pre-processor definition list to allow inclusion of CRT startup code. For more information, see the general configuration setting properties page.
If possible, remove the call to the CRT function that requires the CRT startup code, but use their Win32 equivalent functions. For example, replace strcmp with lstrcmp. Known functions that require CRT startup code are some string and floating point functions.
Compilation and link problems

The project does not reference the Library (. Lib) or object (. OBJ) file. For more information, see the. Lib file used as the linker input.
When the Runtime Library and the MFC Library name are included in the object file module, using/nod will cause lnk2001. If you use the/nod (/nodefalib Lib) option, these libraries are not linked to the project unless they are explicitly included.
When Unicode and MFC are used, if the wwinmaincrtstartup entry point is not created, external objects that cannot be parsed will be obtained on _ winmain @ 16. Use/entry. See the Unicode programming abstract.
For more information, see the following Knowledge Base Article in the msdn library. In the msdn library, click the "Search" tab, paste the article number or title in the text box, and then click "list topics ". If you search by document number, make sure to clear the "search only title" option.

Q125750 "PRB: Error lnk2001: '_ winmain @ 16': unresolved external symbol"
Q131204 "PRB: Wrong project selection causes lnk2001 on _ winmain @ 16"
Q100639 "Unicode support in the Microsoft Foundation Class Library"
Q291952 "PRB: Link error lnk2001: unresolved external symbol _ main"
Linking the Code Compiled with/MT with library libc. Lib will cause lnk2001 on _ beginthread, _ beginthreadex, _ endthread, and _ endthreadex.
Code that links the multi-threaded Library (any MFC code or Code Compiled with/mt) will cause lnk2001 on _ beginthread, _ beginthreadex, _ endthread, and _ endthreadex. For more information, see the following knowledge base articles:
Q126646 "PRB: Error MSG: lnk2001 on _ beginthreadex and _ endthreadex"
Q128641 "Info:/MX compiler options and the libc, libcmt, msvcrt libs"
Q16.04 "PRB: MFC and CRT must match in debug/release and static/dynamic"
When compiling with/MD, because all the runtime libraries are now stored in the DLL, therefore, the reference of "func" in the source changes to "_ imp _ FUNC" reference in the object. If you try to connect to the static library libc. lib or libcmt. Lib, lnk2001 will be obtained on _ imp _ FUNC. If you try to connect to msvcxx. Lib without using/MD for compilation, you may not always get lnk2001, but there may be other problems.
When you link Code Compiled with explicit or implicit/ml to libcmt. Lib, lnk2001 will be generated on _ errno.
Lnk2001 is linked to the release mode library when an application debugging version is generated. Similarly, use the/mxd option (/MLD,/MTD or/MDD) and/or define _ debug, then, linking with the release library will lead to potential external objects that cannot be parsed (and other problems ). Similar problems may occur when the publishing mode is generated and the debugging library is linked.
Mixing the Microsoft library version with the compiler product version may cause problems. The library of the new compiler version may contain new symbols not in the library of the earlier version. You may need to change the directory order in the search path or point them to the current version.
You can change the search sequence in the "Tools", "options", "projects", and "VC ++ directories" dialog box selected from the library file. The "linker" folder in the "property page" dialog box of the project may also contain paths that may have expired.

This issue may occur when a new SDK is installed (which may be in different locations) but the search order is not updated to a new location. In general, you should put the include directory and lib directory path of the new SDK before the default visual c ++ location. In addition, projects that contain the embedded path may still point to the old path, which is valid, but new features added for new versions installed in different locations have expired.

There is currently no C ++ Naming Standard between compiler vendors or even different versions of the same compiler. Therefore, the same naming scheme may not be generated for the object files compiled by other compilers, resulting in lnk2001 error.
Mixed inner and non-inline compilation options on different modules will cause lnk2001. If function inline (/ob1 or/ob2) is enabled when the C ++ library is created, but the inline header file describing the function is closed (no inline keyword ), this error will occur. To prevent this problem, use inline to define the inline function in the header file to be included in other files.
If you use the # pragma inline_depth compiler directive, make sure that it has a value set to 2 or greater and use/ob1 or/ob2 compiler options.
Lnk2001 is caused by omitting the link option/noentry when creating a pure resource DLL.
Incorrect/subsystem or/entry settings will cause lnk2001. For example, if you write a character-based application (console application) and specify/subsystem: Windows, you will get a winmain external object that cannot be parsed. For more information about these options and entry points, see/subsystem and/entry Linker Options.
The created Project is a hosted DLL, which contains Microsoft intermediate language code that is not linked to the local C/C ++ Library (such as CRT, ATL, or MFC ), you add code from the local C/C ++ library that uses static variables. To fix the issue, you must convert the project to the hybrid mode. For more information, see converting a C ++ managed extension project from a pure intermediate language to a hybrid mode.
Export Problems

Lnk2001 occurs when the application is transplanted from 16-bit to 32-bit. The syntax of the current 32-bit module definition (. Def) file requires that the _ cdecl, _ stdcall, and _ fastcall functions are listed in the exports section without underscores (not modified ). This is different from the 16-bit syntax. These functions must be underlined when listed in the 16-bit syntax ). For more information, see the description in the module definition file exports section.
Any export listed in the. Def file but not found will cause lnk2001. This may be because the export does not exist, the spelling is incorrect, or the C ++ modifier is used (The. Def file does not use the modifier ).
Explanation output

If the symbols cannot be parsed, use the following guide to obtain information about functions:

On the X86 platform, the call conventions of the name compiled by C or the extern "C" name in C ++ are modified as follows:

_ Cdecl
The function has an underscore (_) prefix.
_ Stdcall
The function has an underscore (_) prefix and @ suffix, and is aligned with the double length of the parameter on the stack.
_ Fastcall
The function has a @ prefix and a @ suffix, and is aligned with the double font length of the parameter on the stack.
Use undname.exe to obtain the unmodified format of the modifier name.

For more information about the reasons listed above, see:

Function subject or variable missing
Name Modification
This symbol is not public
Automatic (function range) variables
Global constants in c ++
Function inline Problems

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/nova_nwu/archive/2008/11/10/3266376.aspx

 

 

 

 

 

 

P.s:

Generally, there is another one behind,

Faltal error lnk 1120: error.

From the lnk2019 error location (. OBJ), it is more likely that the source file is wrong, because when the file is to. OBJ, it is simply the name resolution. Or the name is C ++/C. Then Link. So check your source files carefully. What is important is some fixed generation. The competency of self-defined functions or other out-of-the-box errors is relatively low.