--??LINK2001
學(xué)習(xí)VC＋＋時(shí)經(jīng)常會(huì)遇到鏈接錯(cuò)誤LNK2001，該錯(cuò)誤非常討厭，因?yàn)閷?duì)于
編程者來(lái)說(shuō)，最好改的錯(cuò)誤莫過(guò)于編譯錯(cuò)誤，而一般說(shuō)來(lái)發(fā)生連接錯(cuò)誤時(shí)，
編譯都已通過(guò)。產(chǎn)生連接錯(cuò)誤的原因非常多，尤其LNK2001錯(cuò)誤，常常使人不
明其所以然。如果不深入地學(xué)習(xí)和理解VC＋＋，要想改正連接錯(cuò)誤LNK2001非
常困難。
　　初學(xué)者在學(xué)習(xí)VC＋＋的過(guò)程中，遇到的LNK2001錯(cuò)誤的錯(cuò)誤消息主要為：
　　unresolved external symbol “symbol”（不確定的外部“符號(hào)”）。
　　如果連接程序不能在所有的庫(kù)和目標(biāo)文件內(nèi)找到所引用的函數(shù)、變量或
標(biāo)簽，將產(chǎn)生此錯(cuò)誤消息。一般來(lái)說(shuō)，發(fā)生錯(cuò)誤的原因有兩個(gè)：一是所引用
的函數(shù)、變量不存在、拼寫(xiě)不正確或者使用錯(cuò)誤；其次可能使用了不同版本
的連接庫(kù)。
　　以下是可能產(chǎn)生LNK2001錯(cuò)誤的原因：
　　一．由于編碼錯(cuò)誤導(dǎo)致的LNK2001。
　　1．不相匹配的程序代碼或模塊定義（.DEF）文件能導(dǎo)致LNK2001。例如,
如果在C＋＋ 源文件內(nèi)聲明了一變量“var1”，卻試圖在另一文件內(nèi)以變量
“VAR1”訪問(wèn)該變量,將發(fā)生該錯(cuò)誤。
　　2．如果使用的內(nèi)聯(lián)函數(shù)是在.CPP文件內(nèi)定義的，而不是在頭文件內(nèi)定
義將導(dǎo)致LNK2001錯(cuò)誤。
　　3．調(diào)用函數(shù)時(shí)如果所用的參數(shù)類(lèi)型同函數(shù)聲明時(shí)的類(lèi)型不符將會(huì)產(chǎn)生
LNK2001。
　　4．試圖從基類(lèi)的構(gòu)造函數(shù)或析構(gòu)函數(shù)中調(diào)用虛擬函數(shù)時(shí)將會(huì)導(dǎo)致LNK2001。
　　5．要注意函數(shù)和變量的可公用性，只有全局變量、函數(shù)是可公用的。
　　靜態(tài)函數(shù)和靜態(tài)變量具有相同的使用范圍限制。當(dāng)試圖從文件外部訪問(wèn)
任何沒(méi)有在該文件內(nèi)聲明的靜態(tài)變量時(shí)將導(dǎo)致編譯錯(cuò)誤或LNK2001。
　　函數(shù)內(nèi)聲明的變量（局部變量） 只能在該函數(shù)的范圍內(nèi)使用。
　　C＋＋ 的全局常量只有靜態(tài)連接性能。這不同于C，如果試圖在C＋＋的
多個(gè)文件內(nèi)使用全局變量也會(huì)產(chǎn)生LNK2001錯(cuò)誤。一種解決的方法是需要時(shí)在
頭文件中加入該常量的初始化代碼，并在.CPP文件中包含該頭文件；另一種
方法是使用時(shí)給該變量賦以常數(shù)。
　　二．由于編譯和鏈接的設(shè)置而造成的LNK2001
　　1．如果編譯時(shí)使用的是/NOD（/NODEFAULTLIB）選項(xiàng)，程序所需要的運(yùn)行
庫(kù)和MFC庫(kù)在連接時(shí)由編譯器寫(xiě)入目標(biāo)文件模塊， 但除非在文件中明確包含
這些庫(kù)名，否則這些庫(kù)不會(huì)被鏈接進(jìn)工程文件。在這種情況下使用/NOD將導(dǎo)
致錯(cuò)誤LNK2001。
　　2．如果沒(méi)有為wWinMainCRTStartup設(shè)定程序入口，在使用Unicode和MFC
時(shí)將得到“unresolved external on _WinMain@16”的LNK2001錯(cuò)誤信息。
　　3．使用/MD選項(xiàng)編譯時(shí),既然所有的運(yùn)行庫(kù)都被保留在動(dòng)態(tài)鏈接庫(kù)之內(nèi)，
源文件中對(duì)“func”的引用，在目標(biāo)文件里即對(duì)“__imp__func” 的引用。
如果試圖使用靜態(tài)庫(kù)LIBC.LIB或LIBCMT.LIB進(jìn)行連接，將在__imp__func上發(fā)
生LNK2001；如果不使用/MD選項(xiàng)編譯，在使用MSVCxx.LIB連接時(shí)也會(huì)發(fā)生LNK2001。
　　4．使用/ML選項(xiàng)編譯時(shí)，如用LIBCMT.LIB鏈接會(huì)在_errno上發(fā)生LNK2001。
　　5．當(dāng)編譯調(diào)試版的應(yīng)用程序時(shí)，如果采用發(fā)行版模態(tài)庫(kù)進(jìn)行連接也會(huì)產(chǎn)
生LNK2001；同樣，使用調(diào)試版模態(tài)庫(kù)連接發(fā)行版應(yīng)用程序時(shí)也會(huì)產(chǎn)生相同的
問(wèn)題。
　　6．不同版本的庫(kù)和編譯器的混合使用也能產(chǎn)生問(wèn)題，因?yàn)樾掳娴膸?kù)里可
能包含早先的版本沒(méi)有的符號(hào)和說(shuō)明。
　　7．在不同的模塊使用內(nèi)聯(lián)和非內(nèi)聯(lián)的編譯選項(xiàng)能夠?qū)е翷NK2001。如果
創(chuàng)建C＋＋庫(kù)時(shí)打開(kāi)了函數(shù)內(nèi)聯(lián)（/Ob1或/Ob2），但是在描述該函數(shù)的相應(yīng)頭
文件里卻關(guān)閉了函數(shù)內(nèi)聯(lián)（沒(méi)有inline關(guān)鍵字），這時(shí)將得到該錯(cuò)誤信息。
為避免該問(wèn)題的發(fā)生，應(yīng)該在相應(yīng)的頭文件中用inline關(guān)鍵字標(biāo)志內(nèi)聯(lián)函數(shù)。
　　8．不正確的/SUBSYSTEM或/ENTRY設(shè)置也能導(dǎo)致LNK2001。
　　其實(shí)，產(chǎn)生LNK2001的原因還有很多，以上的原因只是一部分而已，對(duì)初
學(xué)者來(lái)說(shuō)這些就夠理解一陣子了。但是，分析錯(cuò)誤原因的目的是為了避免錯(cuò)
誤的發(fā)生。LNK2001錯(cuò)誤雖然比較困難，但是只要注意到了上述問(wèn)題，還是能
夠避免和予以解決的。

LNK2019
函數(shù)只有申明,沒(méi)有實(shí)現(xiàn)時(shí),或是DLL中的東東沒(méi)有export啊

unresolved external symbol 'symbol' referenced in function 'function'

An undefined external symbol (symbol) was found in function. To resolve this error, provide a definition for symbol or remove the code that references it.

In Visual C++ .NET 2003, this error will be generated when /clris used and the CRT is not linked into your executable. Any object code generated by the compiler that is not built with /clr:initialAppDomain contains a reference to the _check_commonlanguageruntime_version function, which is defined in the C Runtime Library (CRT). This function provides for an error message if your application is run on version 1 of the runtime. Code generated by the current compiler is not compatible with version 1 of the common language runtime. So, if you compile without the CRT in Visual C++ .NET 2003, you should include a definition of the _check_commonlanguageruntime_version function in your code. As an alternative to using the _check_commonlanguageruntime_version function, you can link with nochkclr.obj, which contains an empty version of the function and does not provide for an error message if you run your application on version 1 of the runtime. To build an application with the current compiler version to run on the previous version of the runtime, use /clr:InitialAppDomain.

To build a pure MSIL executable (does not link with the CRT), you must define the function in your project; you cannot use nochkclr.obj (the .obj is native code). See Producing Verifiable Components with Managed Extensions for C++for more information about verifiable code. For more information on creating a pure MSIL output file from your Managed C++ project, see Converting Managed Extensions for C++ Projects from Mixed-Mode to Pure IL.

The rest of this topic discusses other causes of LNK2019.

Consider the following sample:

extern int i;
extern void g();
void f()
{
   i++;
   g();
}
int main()
{
}

If i and g are not defined in one of the files included in the build, the linker will generate LNK2019. These definitions can be added by including the source code file that contains the definitions as part of the compilation. Alternatively, you can pass .obj or .lib files that contain the definitions to the linker.

For C++ projects from previous releases that were upgraded to the current version, if __UNICODE was defined and the entry point was WinMain, you need to change the name of the entry point function to either _tWinMain or _tmain.

Common problems that cause LNK2019 include:

• The declaration of the symbol contains a spelling mistake, such that, it is not the same name as the definition of the symbol.
• A function was used but the type or number of the parameters did not match the function definition.
• The calling convention (__cdecl, __stdcall, or __fastcall) differs on the use of the function declaration and the function definition.
• Symbol definitions are in a file that was compiled as a C program and symbols are declared in a C++ file without an extern "C" modifier. In that case, modify the declaration, for example, instead of:

  extern int i;
  extern void g();

  use:

  extern "C" int i;
  extern "C" void g();

  Similarly, if you define a symbol in a C++ file that will be used by a C program, use extern "C" in the definition.

• A symbol is defined as static and then later referenced outside the file.
• A static member of a class is not defined. For example, member variable si in the class declaration below should be defined separately:

  #include <stdio.h>
  struct X {
     static int si;
  };
  
  // int X::si = 0;   // uncomment this line to resolve
  
  void main()
  {
     X *px = new X[2];
     printf("\n%d",px[0].si);   // LNK2019
  }

This error can also be generated as a result of conformance work that was done for Visual Studio .NET 2003: template friends and specialization. In Visual Studio?.NET 2003, a friend declaration that declares a new non-template function must be defined.

For code that is valid in both the Visual Studio?.NET 2003 and Visual Studio?.NET versions of Visual C++, explicitly specify the friend function's template argument list.

// LNK2019.cpp
// LNK2019 expected
template<class T>
void f(T)
{
}

template<class T>
struct S
{
   friend void f(T);
   // Try the folowing line instead:
   // friend void f<T>(T);
};

int main()
{
   S<int> s;
   f(1);   // unresolved external
}

The /VERBOSE linker option will help you see which files the linker is referencing. The /EXPORT and /SYMBOLS options of the DUMPBIN utility can also help you see which symbols are defined in your dll and object/library files.