帖子轉自zhhxidian2005的部落格

感謝作者提供內容!

晚風也渡 發表於 2003-1-9 17:51:45
主題 VC＋＋的連結錯誤LNK2001(ZT)

學習VC＋＋時經常會遇到連結錯誤LNK2001，該錯誤非常討厭，因為對於
程式設計者來說，最好改的錯誤莫過於編譯錯誤，而一般說來發生連線錯誤時，
編譯都已通過。產生連線錯誤的原因非常多，尤其LNK2001錯誤，常常使人不
明其所以然。如果不深入地學習和理解VC＋＋，要想改正連線錯誤LNK2001非
常困難。
　　初學者在學習VC＋＋的過程中，遇到的LNK2001錯誤的錯誤訊息主要為：
　　unresolved external symbol “symbol”（不確定的外部“符號”）。
　　如果連線程式不能在所有的庫和目標檔案內找到所引用的函式、變數或
標籤，將產生此錯誤訊息。一般來說，發生錯誤的原因有兩個：一是所引用
的函式、變數不存在、拼寫不正確或者使用錯誤；其次可能使用了不同版本
的連線庫。
　　以下是可能產生LNK2001錯誤的原因：
　　一．由於編碼錯誤導致的LNK2001。
　　1．不相匹配的程式程式碼或模組定義（.DEF）檔案能導致LNK2001。例如,
如果在C＋＋ 原始檔內聲明瞭一變數“var1”，卻試圖在另一檔案內以變數
“VAR1”訪問該變數,將發生該錯誤。
　　2．如果使用的行內函數是在.CPP檔案內定義的，而不是在標頭檔案內定
義將導致LNK2001錯誤。
　　3．呼叫函式時如果所用的引數型別同函式宣告時的型別不符將會產生
LNK2001。
　　4．試圖從基類的建構函式或解構函式中呼叫虛擬函式時將會導致LNK2001。
　　5．要注意函式和變數的可公用性，只有全域性變數、函式是可公用的。
　　靜態函式和靜態變數具有相同的使用範圍限制。當試圖從檔案外部訪問
任何沒有在該檔案內宣告的靜態變數時將導致編譯錯誤或LNK2001。
　　函式內宣告的變數（區域性變數） 只能在該函式的範圍內使用。
　　C＋＋ 的全域性常量只有靜態連線效能。這不同於C，如果試圖在C＋＋的
多個檔案內使用全域性變數也會產生LNK2001錯誤。一種解決的方法是需要時在
標頭檔案中加入該常量的初始化程式碼，並在.CPP檔案中包含該標頭檔案；另一種
方法是使用時給該變數賦以常數。
　　二．由於編譯和連結的設定而造成的LNK2001
　　1．如果編譯時使用的是/NOD（/NODEFAULTLIB）選項，程式所需要的執行
庫和MFC庫在連線時由編譯器寫入目標檔案模組， 但除非在檔案中明確包含
這些庫名，否則這些庫不會被連結進工程檔案。在這種情況下使用/NOD將導
致錯誤LNK2001。
　　2．如果沒有為wWinMainCRTStartup設定程式入口，在使用Unicode和MFC
時將得到“unresolved external on

[email protected]”的LNK2001錯誤資訊。
　　3．使用/MD選項編譯時,既然所有的執行庫都被保留在動態連結庫之內，
原始檔中對“func”的引用，在目標檔案裡即對“__imp__func” 的引用。
如果試圖使用靜態庫LIBC.LIB或LIBCMT.LIB進行連線，將在__imp__func上發
生LNK2001；如果不使用/MD選項編譯，在使用MSVCxx.LIB連線時也會發生LNK2001。
　　4．使用/ML選項編譯時，如用LIBCMT.LIB連結會在_errno上發生LNK2001。
　　5．當編譯除錯版的應用程式時，如果採用發行版模態庫進行連線也會產
生LNK2001；同樣，使用除錯版模態庫連線發行版應用程式時也會產生相同的
問題。
　　6．不同版本的庫和編譯器的混合使用也能產生問題，因為新版的庫裡可
能包含早先的版本沒有的符號和說明。
　　7．在不同的模組使用內聯和非內聯的編譯選項能夠導致LNK2001。如果
建立C＋＋庫時打開了函式內聯（/Ob1或/Ob2），但是在描述該函式的相應頭
檔案裡卻關閉了函式內聯（沒有inline關鍵字），這時將得到該錯誤資訊。
為避免該問題的發生，應該在相應的標頭檔案中用inline關鍵字標誌行內函數。
　　8．不正確的/SUBSYSTEM或/ENTRY設定也能導致LNK2001。
　　其實，產生LNK2001的原因還有很多，以上的原因只是一部分而已，對初
學者來說這些就夠理解一陣子了。但是，分析錯誤原因的目的是為了避免錯
誤的發生。LNK2001錯誤雖然比較困難，但是隻要注意到了上述問題，還是能
夠避免和予以解決的。

msdn給的說明

Linker Tools Error LNK2001

unresolved external symbol "symbol"

Code will generate this error message if it references something (like a function, variable, or label) that the linker can’t find in all the libraries and object files it searches. In general, there are two reasons this error occurs: what the code asks for doesn’t exist (the symbol

Numerous kinds of coding and build errors can cause LNK2001. Several specific causes are listed below, and some have links to more detailed explanations.

Coding Problems

• Mismatched case in your code or module-definition (.DEF) file can cause LNK2001. For example, if you named a variable “var1” in one C++ source file and tried to access it as “VAR1” in another, you would receive this error. The solution is to exactly match the case of the symbol in all references.
  
• A project that uses function inlining yet defines the functions in a .CPP file rather than in the header file can cause LNK2001. 
  
• If you are using C++, make sure to use extern “C” when calling a C function from a C++ program. By using extern “C” you force the use of the C naming convention. Be aware of compiler switches like /Tp or /Tc that force a file to be compiled as a C (/Tc) or C++ (/Tp) file no matter what the filename extension, or you may get different function names than you expect.
  
• Attempting to reference functions or data that don't have external linkage causes LNK2001. In C++, inline functions and const data have internal linkage unless explicitly specified as extern. 
  
• A missing function body or variable will cause LNK2001. Having just a function prototype or extern declaration will allow the compiler to continue without error, but the linker will not be able to resolve your call to an address or reference to a variable because there is no function code or variable space reserved. 
  
• Name decoration incorporates the parameters of a function into the final decorated function name. Calling a function with parameter types that do not match those in the function declaration may cause LNK2001. 
  
• Incorrectly included prototypes will cause the compiler to expect a function body that is not provided. If you have both a class and non-class implementation of a function F, beware of C++ scope-resolution rules. 
  
• When using C++, make sure that you include the implementation of a specific function for a class and not just a prototype in the class definition. 
  
• Attempting to call a pure virtual function from the constructor or destructor of an abstract base class will cause LNK2001 since by definition a pure virtual function has no base class implementation. 
  
• Only global functions and variables are public.

  Functions declared with the static modifier by definition have file scope. Static variables have the same limitation. Trying to access any static variables from outside of the file in which they are declared can result in a compile error or LNK2001.

  A variable declared within a function (a local variable) can only be used within the scope of that function.

  C++ global constants have static linkage. This is different than C. If you try to use a global constant in C++ in multiple files you get error LNK2001. One alternative is to include the const initializations in a header file and include that header in your .CPP files when necessary, just as if it was a function prototype. Another alternative is to make the variable non-constant and use a constant reference when assessing it.

Compiling and Linking Problems

• The names of the Microsoft run-time and MFC libraries needed at link time are included in the object file module by the Microsoft compiler. If you use the /NOD (/NODEFAULTLIB) option, these libraries will not be linked into the project unless you have explicitly included them. Using /NOD will cause error LNK2001 in this case. 
  
• If you are using Unicode and MFC, you will get an unresolved external on _[email protected] if you don’t create an entrypoint towWinMainCRTStartup. Use the /ENTRY option or type this value in the Project Settings dialog box. (To find this option in the development environment, click Settings on the Project menu, then click the Link tab, and click Output in the Category box.) SeeUnicode Programming Summary. 
  
  See the following Knowledge Base articles located in the Online Information System for more information. An easy way to reach an article is to copy a "Q" number above, open the Search dialog box from the Help menu and select the Query tab, then paste the number into the first text box and press ENTER.
  • 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"
• Linking code compiled with /MT with the library LIBC.LIB causes LNK2001 on _beginthread, _beginthreadex, _endthread, and_endthreadex. 
  
• When compiling with /MD, a reference to "func" in your source becomes a reference "__imp__func" in the object since all the run-time is now held within a DLL. If you try to link with the static libraries LIBC.LIB or LIBCMT.LIB, you will get LNK2001 on __imp__func. If you try to link with MSVCxx.LIB when compiling without /MD you will not always get LNK2001, but you will likely have other problems. 
  
• Linking code compiled with an explicit or implicit /ML to the LIBCMT.LIB causes LNK2001 on _errno. 
  
• Linking with the release mode libraries when building a debug version of an application can cause LNK2001. Similarly, using an /Mxd option (/MLd, /MTd, or /MDd) and/or defining _DEBUG and then linking with the release libraries will give you potential unresolved externals (among other problems). Linking a release mode build with the debug libraries will also cause similar problems.
  
• Mixing versions of Microsoft libraries and compiler products can be problematic. A new compiler version's libraries may contain new symbols that cannot be found in the libraries included with previous versions. Use DUMPBIN to find out if a symbol is in a 32-bit object file or library. 
  
• There is currently no standard for C++ naming between compiler vendors or even between different versions of a compiler. Therefore linking object files compiled with other compilers may not produce the same naming scheme and thus cause error LNK2001.
  
• Mixing inline and non-inline compile options on different modules can cause LNK2001. If a C++ library is created with function inlining turned on (/Ob1 or /Ob2) but the corresponding header file describing the functions has inlining turned off (no inline keyword), you will get this error. To prevent this problem, have the inline functions defined with inline in the header file you are going to include in other files.
  
• If you are using the #pragma inline_depth compiler directive, make sure you have a value of 2 or greater set, and make sure you are using the /Ob1 or /Ob2 compiler option. 
  
• Omitting the LINK option /NOENTRY when creating a resource-only DLL will cause LNK2001.
  
• Using incorrect /SUBSYSTEM or /ENTRY settings can cause LNK2001. For example, if you write a character-based application (a console application) and specify /SUBSYSTEM:WINDOWS, you will get an unresolved external for WinMain. For more information on these options and entry points, see the /SUBSYSTEM and /ENTRY linker options.

Export Problems

• When you are porting an application from 16 to 32 bits, LNK2001 can occur. The current 32-bit module-definition (.DEF) file syntax requires that __cdecl, __stdcall, and __fastcall functions be listed in the EXPORTS section without underscores (undecorated). This differs from the 16-bit syntax, where they must be listed with underscores (decorated). For more information, see the description of theEXPORTS section of module-definition files. 
  
• Any export listed in the .DEF file and not found will cause LNK2001. This could be because it does not exist, is spelled incorrectly, or uses decorated names (.DEF files do not take decorated names). 

This error message is followed by fatal error LNK1120.

The following sections give more detailed information on some of the issues named in the above list.