-- LINK2001
学习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 _WinMain@16”的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错误虽然比较困难，但是只要注意到了上述问题，还是能
够避免和予以解决的。
LNK2019函数只有申明,没有实现时,或是DLL中的东东没有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.