马化滕加盟佳莱公司了:VC7编译问题

Visual C++ 概念：生成 C/C++ 程序
链接器工具错误 LNK2019

语言筛选器： 全部 语言筛选器： 多个 语言筛选器： Visual Basic 语言筛选器： C# 语言筛选器： C++ 语言筛选器： J# 语言筛选器： JScript
Visual Basic（声明）
Visual Basic（用法）
C#
C++
J#
JScript

错误消息
在函数“function”中引用了无法解析的外部符号“symbol”

在 function 中找到了未定义的外部符号 (symbol)。若要解决此错误，请提供符号定义或移除引用它的代码。有关更多信息，请参见，

函数内联问题

自动（函数范围）变量

缺少函数体或变量

下面的示例生成 LNK2019：

复制代码
// LNK2019.cpp
// LNK2019 expected
extern char B[100]; // B is not in avilable to the linker
int main() {
B[0] = ' ';
}

声明但不定义静态数据成员时，也可能出现 LNK2019。下面的示例生成 LNK2019：

复制代码
// LNK2019b.cpp
// LNK2019 expected
struct C {
static int s;
};

// Uncomment the following line to resolve.
// int C::s;

int main() {
C c;
C::s = 1;
}

请看下面的示例：

复制代码
// LNK2019c.cpp
// LNK2019 expected
extern int i;
extern void g();
void f() {
i++;
g();
}
int main() {}

如果在生成中包含的某个文件中没有定义 i 和 g，链接器将生成 LNK2019。可以添加这些定义，方法是将包含这些定义的源代码文件包括为编译的一部分。或者可以将包含这些定义的 .obj 或 .lib 文件传递给链接器。

对于从早期版本升级到当前版本的 C++ 项目，如果定义了 __UNICODE 并且入口点为 WinMain，需要将入口点函数的名称更改为 _tWinMain 或 _tmain。

导致 LNK2019 的常见问题有：

符号声明包含拼写错误，以致于符号声明与符号定义不同。

使用了一个函数，但其参数的类型或数量与函数定义不匹配。

函数声明使用和函数定义使用中的调用约定（__cdecl、__stdcall 或 __fastcall）不同。

符号定义在编译为 C 程序的文件中，而符号是在 C++ 文件中不带 extern "C" 修饰符声明的。在此情况下，请修改声明，例如不是使用：

复制代码
extern int i;
extern void g();

而使用：

复制代码
extern "C" int i;
extern "C" void g();

同样，如果在将由 C 程序使用的 C++ 文件中定义符号，请在定义中使用 extern "C"。

符号定义为静态，但稍后在文件外部被引用。与 C 不同，在 C++ 中全局常数具有 static 链接。若要避免此限制，可以将 const 初始化包括在头文件中，并将此头包括在 .cpp 文件中，也可以使变量成为非常数，然后使用常数引用访问它。

没有定义静态类成员。例如，应单独定义下面类声明中的成员变量 si：

复制代码
// LNK2019d.cpp
#include <stdio.h>
struct X {
static int si;
};

// int X::si = 0; // uncomment this line to resolve

int main() {
X *px = new X[2];
printf_s("\n%d",px[0].si); // LNK2019
}

下面的示例生成与用户定义的运算符有关的 LNK2019。

复制代码
// LNK2019e.cpp
// compile with: /EHsc
// LNK2019 expected
#include <iostream>
using namespace std;

template<class T> class
Test {
friend ostream& operator<<(ostream&, Test&);
// Uncomment the following line to resolve.
// template<typename T> friend ostream& operator << (ostream&, Test<T>&);
};

template<typename T>
ostream& operator<<(ostream& os, Test<T>& tt) {
return os;
}

int main() {
Test<int> t;
cout << "Test: " << t << endl; // unresolved external
}

/VERBOSE 链接器选项帮助您查看链接器引用的文件。DUMPBIN 实用工具的 /EXPORTS 和 /SYMBOLS 选项还可以帮助您查看在 dll 和对象/库文件中定义的符号。

Microsoft 知识库中包含有关 LNK2019 的更多信息，请参见 http://support.microsoft.com/default.aspx?ln=zh-cn。

为 Visual Studio .NET 2003 进行的一致性工作（模板友元和专用化）也可能导致 LNK2019。在 Visual Studio .NET 2003 中，除非在友元声明中显式指定了模板参数，否则与函数模板同名的友元函数的声明不会引用该函数模板。

如果您未指定模板参数，则友元声明将声明一个非模板函数。

有关更多信息，请参见编译时的重大更改摘要。

要使代码在 Visual C++ 的 Visual Studio .NET 2003 和 Visual Studio .NET 版本中均有效，请显式指定友元函数的模板参数列表。

复制代码
// LNK2019f.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
}

在 Visual C++ 2005 中执行的一致性工作也可能导致 LNK2019；现在，默认情况下 /Zc:wchar_t 处于打开状态。可能不是所有模块都使用相同的 /Zc:wchar_t 设置编译的，这样，类型引用便没有解析为可兼容的类型。要解决此问题，请确保所有模块中的类型都是兼容的，方法是使用相应的 /Zc:wchar_t 设置进行编译（例如，要使用 Visual C++ 2005 工具集生成与以前版本中的模块链接的模块，请使用 /Zc:wchar_t-），或者尽可能更新类型以使其兼容。

现在，由于 /Zc:wchar_t 在默认情况下处于打开状态，从注释杂注或通过命令行显式引用 comsupp.lib 应改为使用 comsuppw.lib 或 comsuppwd.lib。使用 /Zc:wchar_t- 进行编译时仍应使用 comsupp.lib。

有关更多信息，请参见 Breaking Changes in the Visual C++ 2005 Compiler 和 /Zc:wchar_t（wchar_t 是本机类型）。

下面的示例创建一个导出，该导出使用解析为 wchar_t 的 WCHAR。

复制代码
// LNK2019g.cpp
// compile with: /LD
#include "windows.h"
// WCHAR resolves to wchar_t
__declspec(dllexport) void func(WCHAR*) {}

下面的示例生成 LNK2019：

复制代码
// LNK2019h.cpp
// compile with: LNK2019g.lib
// LNK2019 expected
__declspec(dllimport) void func(unsigned short*);

int main() {
func(0);
}

若要解决此错误，请将 unsigned short 更改为 wchar_t 或 WCHAR，或使用 /Zc:wchar_t- 编译 LNK2019g.cpp。

如果使用 /SUBSYSTEM:WINDOWS 生成控制台应用程序，也可能出现 LNK2019。无法解析的符号将是 _WinMain@16。在这种情况下，只需使用 /SUBSYSTEM:CONSOLE 进行链接。

换成英文名?