C + + linker Tools Error: LNK2001, LNK2019 (reprint)

This is the category that belongs to the linker tools error.

unresolved external symbol "symbol"

The code refers to something (such as a function, variable, or label) that the linker cannot find in the library and object files.

Possible causes

• The content requested by the code does not exist (for example, a symbolic spelling error or using the wrong case).
• The content of the code request is wrong (using a mixed version of the library, some libraries come from one version of the product, others are from another version).

The error message is followed by a fatal error LNK1120.

Specific reasons

Code issues

• If the LNK2001 diagnostic text report __check_commonlanguageruntime_version is an unresolved external symbol, see LNK2019 for information about how to resolve the problem.
• The definition of a member template is beyond the scope of the class. One limitation of Visual C + + is that the definition of a member template must reside entirely within a enclosing class. For more information about LNK2001 and member templates, see Knowledge Base article Q239436.
• A case mismatch in a code or module definition (. def) file can cause LNK2001. For example, when you name a variable in a C + + source file var1 and try to access the variable in another source file VAR1 .
• If the project uses a function inline, but the function is defined in a. cpp file instead of a header file, it causes LNK2001.
• Calling C functions from a C + + program without using extern "C" (which causes the compiler to use the C naming convention) causes LNK2001. Compiler Options /tp and /tc cause the compiler to compile files into C or C + + independently of the file name extension. These options cause the function name to be different from the name you expect.
• Attempting to reference a function or data that has no external linkage can cause LNK2001. In C + +, inline functions and const data have internal links unless explicitly specified as extern.
• missing function principals or variables can cause LNK2001. If there is only a function prototype or extern declaration, the compiler continues to run without any errors, but the linker will not be able to resolve address calls or variable references because there is no reserved function code or variable space.
• Calling a function with a parameter type that does not match the type of the parameter in the function declaration causes LNK2001. The name decoration merges the function parameters into the final decorated function name.
• An error contains a prototype that causes the compiler to need a function body that is not provided, which results in LNK2001. If you have both F class implementations and non-class implementations of functions, be aware of C + + scope resolution rules.
• When using C + +, a function prototype is included in the class definition but fails to contain the implementation (the implementation of this function of the class) causes LNK2001.
• Attempting to call a pure virtual function from a constructor or destructor of an abstract base class causes LNK2001. Pure virtual functions do not have a base class implementation.
• Attempting to access the static variable from outside the file that contains the static variable declaration causes LNK2001. By definition, a function declared with the Static modifier has a file scope. Static variables have the same limitations.
• Attempting to use a variable ( local variable ) declared with the function outside the scope of the function causes LNK2001.
• Attempting to use C + + global constants in multiple files can cause LNK2001. Unlike C, Global constants have static links in C + +. To avoid this limitation, you can include the const initialization in the header file and include the header in the. cpp file, or you can make the variable a very number, and then use a constant reference to access it.
• When building a release version of an ATL project, it indicates that the CRT startup code is required. To fix, do one of the following:
  • Remove _atl_min_crt from the preprocessor definition list to allow the CRT startup code to be included. For more information, see General Configuration Settings Property page .
  • If possible, remove the calls to CRT functions that require CRT startup code and use their WIN32 equivalent functions instead. For example, use lstrcmp instead of strcmp. Known functions that require CRT startup code are some string and floating-point functions.

Compile and link issues

• The project is missing a library (. LIB) or an object (. OBJ) file is referenced. For more information, see . lib files that are used as linker inputs .
• Using/nod when the name of the runtime library and the MFC Library is included in the object file module causes LNK2001. If you use the/nod (/nodefaultlib) option, these libraries will not be linked to the project unless they are explicitly included.
• When using Unicode and MFC, if you do not create an entry point for wWinMainCRTStartup , you will get an unresolved external object in _[email protected] ; use /entry . See Unicode Programming Summary .

  For more information, see the following Knowledge Base articles in the MSDN Library. In the MSDN Library, click the Search tab, paste the article number or the article title in the text box, and then click List Topics. If you search by article number, make sure the Search titles only option is cleared.

  • Q125750 "Prb:error LNK2001: ' [email protected] ': Unresolved External Symbol '
  • Q131204 "Prb:wrong Project Selection causes LNK2001 on [email protected]"
  • Q100639 "Unicode support in the Microsoft Foundation Class Library"
  • Q291952 "Prb:link Error lnk2001:unresolved External Symbol _main"
• The/MT compiled code and library LIBC.lib links will be in _beginthread,_beginthreadex,_endthread , and _endthreadex result in LNK2001.
• Linking code that requires multiline libraries (any MFC code or code compiled with /MT ) will be in _beginthread,_beginthreadex, _endthread, and _endthreadex result in LNK2001. 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"
  • Q166504 "Prb:mfc and CRT must Match in Debug/release and Static/dynamic"
• When compiling with /MD , because all runtimes are now stored in the DLL, the "func" reference in the source becomes a "__imp__func" reference in the object. If you attempt to link to a static library LIBC.lib or LIBCMT.lib, you will get LNK2001 on __imp__func . When compiling without/MD, if you try to link to MSVCxx.lib, you do not always get LNK2001, but there may be other problems.
• Linking code compiled with explicit or implicit /ml to LIBCMT.lib will cause LNK2001 on _errno .
• Linking to the Publish Schema Library when you build the debug version of the application causes LNK2001. Similarly, use the/mxd option (/mld,/mtd , or /mdd) and/or define _DEBUG, Then linking to the publishing library brings potential unresolved external objects (and other issues). Linking the release mode generation to the debug library can also cause similar problems.
• Mixing the Microsoft library version with the compiler product version may be problematic. The new compiler version of the library may contain new symbols that are not in the previous version of the library. You may need to change the order of the directories in the search path, or make them point to the current version.

  From the library file selection under "Tools" | "Options" | "Project" | VC + + Directory dialog box, you can change the search order. The linker folder in the Project's Property Pages dialog box may also contain paths that may have expired.

  This problem may occur when the new SDK is installed (possibly in a different location), but the search order is not updated to point to the new location. Typically, you should place the path of the new SDK's include directory and the Lib directory in front of the default Visual C + + location. Additionally, items that contain embedded paths may still point to the old path, which is valid, but new features that are added to new versions installed to different locations have expired.

• There is currently no C + + naming standard between compiler vendors and even different versions of the same compiler. Therefore, object files that are linked with other compilers may not produce the same naming scheme, resulting in error LNK2001.
• mixing inline and non-inline compilation options on different modules results in LNK2001. This error occurs when the function inline (/ob1 or/OB2) is opened when a C + + library is created, but the inline of the corresponding header file that describes the function is closed (without the inline keyword). To prevent this problem, define inline functions with inline in the header file that you want to include in the other file.
• If you use the #pragma inline_depth compiler directive, make sure that you have a value set to 2 or greater , and make sure that you use the /ob1 or /ob2 compiler option.
• Omitting the LINK option when creating a resource-only DLL/noentry will result in LNK2001.
• Using an incorrect/subsystem or/entry setting can cause LNK2001. For example, if you write a character-based application (a console application) and specify/subsystem:windows, you will get an unresolved WinMain external object. For more information about these options and entry points, see /subsystem and /entry linker options.
• The project you are creating is a managed DLL that contains the Microsoft intermediate language code that is not linked to a native C + + library (such as CRT, ATL, or MFC), and you are adding code from a native C + + library that uses static variables. To fix, you must convert the project to mixed mode. For more information, see

From: http://www.zahui.com/html/9/35690.htm

Programming summary

To take advantage of MFC and C Runtime support for Unicode, you need:

• Define _unicode.

  Define the _unicode symbol before generating the program.

• Specifies the entry point.

  In the project's Property Pages dialog box, in the output page of the linker folder, set the entry point symbol for the wWinMainCRTStartup .

• Use the "portable" run-time functions and types.

  Use the correct C run-time function for Unicode string processing. You can use the WCS function Family, but you might prefer to use a fully "portable" (internationalization-enabled)_TCHAR macro. These macros are prefixed with _tcs , and they replace the str function Family one-to-one. These functions are described in detail in the internationalization section of the run-time library reference. For more information, see TCHAR. General text mappings in H .

  Use the _tchar and related portable data types that are described in support for Unicode .

• The
• handles the string correctly. The

  Visual C + + compiler interprets the encoded string as

  L "This is a literal string" 

  The

  Indicates that this is a string of Unicode characters. You can use the same prefix for literal characters. Strings are generally encoded using the _t macro, so strings are compiled into Unicode strings under Unicode, and strings are compiled to ANSI strings (including MBCS) when Unicode is not used. For example, do not use:

  pwnd->setwindowtext ("Hello"); 

  Instead of using:

  pwnd->setwindowtext (_t ("Hello")); 

  The

  uses the defined _unicode , _t to translate the string into a format prefixed with L, otherwise _t translates the string into a format without the L prefix.

  tips     _t macros with _text macros are the same.

• Be careful when passing string lengths to functions.

  Some functions need to get the number of characters in a string, while others need to get the number of bytes in the string. For example, if you have defined _unicode, the following calls to the CArchive object are not valid ( str CString):

  Archive. Write (str, str. GetLength ());    Invalid

  In a Unicode application, because each character is double-byte wide, the length gives the number of characters but does not give the correct number of bytes. So you must use:

  Archive. Write (str, str. GetLength () * sizeof (_TCHAR));    Valid

  It specifies the correct number of bytes to write.

  However, MFC member functions are character-oriented rather than byte-oriented, so this additional encoding is not required:

  Pdc->textout (str, str. GetLength ());

  Cdc::textout takes a number of characters instead of bytes.

In summary, MFC and the runtime library provide the following support for Unicode programming under Windows 2000:

• In addition to the database class member functions, all MFC (including CString) functions support Unicode. CString also provides unicode/ansi conversion functions.
• The run-time library provides a Unicode version of all string-handling functions. (The run-time library also provides a "portable" version that is suitable for Unicode or MBCS.) These versions are _TCS macros. ）
• TCHAR. H provides portable data types as well as _t macros that translate strings and characters. See TCHAR. General text mappings in H .
• The run-time library provides a wide-character version of main . Use wmain to make an application "Unicode aware."

Please see

Unicode supported

Linker Tools Error LNK2019

C + + linker Tools Error: LNK2001, LNK2019 (reprint)