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

MFC编译运行错误之error LNK2019error 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 struct X static int si;/ int X:si = 0; / uncomment this line to resolvevoid main() X *px = new X2; printf(n%d,px0.si); / LNK20198.也可能由于为 Visual Studio .NET 2003 进行的一致性工作生成此错误：模板友元和专用化。在 Visual Studio .NET 2003 中，必须定义声明新的非模板函数的友元声明。要使代码在 Visual C+ 的 Visual Studio .NET 2003 和 Visual Studio .NET 版本中均有效，请显式指定友元函数的模板参数列表。/ LNK2019.cpp/ LNK2019 expectedtemplatevoid f(T)templatestruct S friend void f(T); / Try the folowing line instead: / friend void f(T);int main() S s; f(1); / unresolved external/VERBOSE 链接器选项帮助您查看链接器引用的文件。DUMPBIN 实用工具的 /EXPORT 和 /SYMBOLS 选项还可以帮助您查看 dll 和对象/库文件中定义的符号。-例如“error LNK2019: 无法解析的外部符号_imp_SetupDiGetDeviceInterfaceDetailW24error LNK2001: 无法解析的外部符号“private: static struct _OVERLAPPED CUsbCom:g_WriteOverlapped”应该是工程设置的问题 没有连接相应的lib库或者是所用到的函数没定义（这个定义是在别的类里面的）当出现error LNK2001: 无法解析的外部符号 _print_interface log.obj 可在log.c里搜print_interface（无前面_），找到此函数，看有无定义学习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文件中包含该头文件；另一种 方法是使用时给该变量赋以常数。二由于编译和链接的设置而造成的LNK20011如果编译时使用的是/NOD（/NODEFAULTLIB）选项，程序所需要的运行库和MFC库在连接时由编译器写入目标文件模块， 但除非在文件中明确包含 这些库名，否则这些库不会被链接进工程文件。在这种情况下使用/NOD将导 致错误LNK2001。2如果没有为wWinMainCRTStartup设定程序入口，在使用Unicode和MFC时将得到“unresolved external on _WinMain16”的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错误虽然比较困难，但是只要注意到了上述问题，还是能够避免和予以解决的。既然编译通过了，就说明了没有语法错误，不用在代码中死抠语法了。从错误中提示中找原因吧。一般问题出在（1）XXX.lib头文件，这个要包含（不然编译也不能通过）（2）需要XXX.lib或XXX.dll库。手动添加，项目-属性-配置属性-链接器-输入 然后在附件依赖项添加XXX.lib，再生成第一个无法解析的外部符号错误消失了。=18、Visual Studio 2005不能进行调试，错误126: 找不到指定的模块Visual Studio 2005一直不能进行调试，查看出错的原因，是因为Terminal Services服务不能正确启动。在【服务】里尝试启动Termial Services服务时，一直提示【错误126: 找不到指定的模块】的错。上网搜索了一下，发现了这样的信息：错误126：找不到指定的模块1 故障现象尝试在“服务”管理单元窗口手动启动服务时，系统提示“错误126：找不到指定的模块”(Error 126: The specified module could not be found.)， 2原因分析该故障通常在由svchost服务宿主进程所启动的服务上发生。这一类的Windows服务，其实是以dll模块的形式插入某个 svchost进程。如果该dll文件被破坏，或者注册表的相关键值被篡改，都可能导致问题。这类服务所对应的Dll文件，是由HKLMSYSTEM CurrentControlSetServicesServiceNameParameters注册表项下的ServiceDll键值所定义的 (此处的Serv