MFC编译运行错误之errorLNK2019解释.docVIP

MFC编译运行错误之error LNK2019 error LNK2019: 无法解析的外部符号....该符号在函数 ...中被引用 这种情况一般都是函数只找到声明但没有实现，或者是少了什么链接库，你可以试试把那两个.h和.c文件直接加入工程中再试试。 有一个解决方案，有两个工程A，B。工程B中定义了一个类，在工程A的demo.cpp中引用该类，但是如果是 #include XX,h，则会出现“error LNK2019: 无法解析的外部符号” 如果是#include XX.cpp，则可以顺利编译通过。 想来是因为引用 .h 文件导致找不到.cpp中的定义，而引用.cpp可以通过.cpp找到.h(.cpp有对.h的include) 但是如果同在工程B下面，则#include XX,h也是正确的，它会自动关联到同名的（反正是对应的）.cpp文件。 在不同工程中应该如何引用呢？ 看见一种原因分析，如下： 现场情况： funcname 在文件file.cpp/h中定义实现 void funcname(void) {;} filecall.c文件内呼叫funcname()函数。 出现上面情况。 症因：因c/c++混合编程， c文件内函数无法呼叫c++文件内函数。 解决，或者将c文件名改为.cpp，或者将c++文件名改为.c 上面的解决采用将 file.cpp 更名为file.c即可。 1. 在 Visual C++ .NET 2003 中，如果使用了 /clr 而未将 CRT 链接到可执行文件，将生成此错误。任何由编译器在未使用 /clr:initialAppDomain 时生成的对象代码都包含对 _check_commonlanguageruntime_version 函数的引用，该函数在 C 运行时库 (CRT) 中定义。如果应用程序在运行库的版本 1 上运行，该函数将会生成一个错误信息。当前编译器生成的代码与运行库的版本 1 不兼容。因此，如果在 Visual C++ .NET 2003 中编译时不使用 CRT，则应在代码中包含 _check_commonlanguageruntime_version 函数的定义。作为使用 _check_commonlanguageruntime_version 函数的替代方法，您可以与 nochkclr.obj 链接。nochkclr.obj 包含该函数的一个空版本，当您在运行库的版本 1 上运行应用程序时，nochkclr.obj 不生成错误信息。若要使用当前编译器版本生成应用程序以在运行库的以前版本上运行，应使用 /clr:InitialAppDomain。 若要 生成一个纯 MSIL 可执行文件（不与 CRT 链接），则必须在项目中定义该函数，而不能使用 nochkclr.obj（.obj 是本机代码）。有关可验证代码的更多信息，请参见产生可验证的 C++ 托管扩展组件。有关从托管 C++ 项目创建纯 MSIL 输出文件的更多信息，请参见将 C++ 托管扩展项目从混合模式转换成纯 IL。 2. 请看下面的示例： extern int i; extern void g(); void f() { i++; g(); } int main() { } 如果在生成中包含的某个文件中没有定义 i 和 g，链接器将生成 LNK2019。可以添加这些定义，方法是将包含这些定义的源代码文件包括为编译的一部分。或者可以将包含这些定义的 .obj 或 .lib 文件传递给链接器。 3. 对于从早期版本升级到当前版本的 C++ 项目，如果定义了 __UNICODE 并且入口点为 WinMain，需要将入口点函数的名称更改为 _tWinMain 或 _tmain。 4. 符号声明包含拼写错误，以致于符号声明与符号定义不同。 5. 使用了一个函数，但其参数的类型或数量与函数定义不匹配。 函数声明使用和函数定义使用中的调用约定（__cdecl、__stdcall 或 __fastcall）不同。 6. 符号定义在编译为 C 程序的文件中，而符号是在 C++ 文件中不带 extern C 修饰符声明的。在此情况下，请修改声明，例如不是使用： extern int i; extern void g(); 而使用： extern C int i; extern C void g(); 同样，如果在将由 C 程序使用的 C++ 文件中定义符号，请在定义中使用 extern C。 7. 符号定义为静态，但稍后在文件外部被引用。 没有定义静态类成员。例如，应单独定义下面类声明中的成员变量 si： #include stdio.h struct X { static int si; }; // int X::si = 0; /