C++链接器工具错误:LNK2001, LNK2019

转载 2015年12月26日 00:45:11

这是归属于链接器工具错误 这一类。

无法解析的外部符号“symbol”

代码引用了链接器无法在库和对象文件中找到的内容(如函数、变量或标签)。

可能的原因

  • 代码请求的内容不存在(例如,符号拼写错误或使用错误的大小写)。
  • 代码请求的内容错误(使用的是混合版本的库,一些库来自产品的一个版本,而其他则来自另一个版本)。

该错误信息之后为致命错误 LNK1120

具体原因

代码问题

  • 如果 LNK2001 诊断文本报告 __check_commonlanguageruntime_version 是无法解析的外部符号,可参见 LNK2019 了解如何解决该问题的信息。
  • 成员模板的定义超出了类的范围。Visual C++ 的一个限制是,成员模板的定义必须完全位于封闭类内。有关 LNK2001 和成员模板的更多信息,请参见知识库文章 Q239436。
  • 代码或模块定义 (.def) 文件中的大小写不匹配会导致 LNK2001。例如,当在一个 C++ 源文件中将一个变量命名为 var1,并试图在另一个源文件中以 VAR1 访问该变量时。
  • 如果项目使用函数内联,但在 .cpp 文件而非头文件中定义函数,则会导致 LNK2001。
  • 从 C++ 程序调用 C 函数但不使用 extern "C"(这导致编译器使用 C 命名约定)会导致 LNK2001。编译器选项 /Tp 和 /Tc 使编译器将文件分别编译为 C 或 C++,与文件扩展名无关。这些选项会导致函数名与您所期望的名称不同。
  • 试图引用没有外部链接的函数或数据会导致 LNK2001。在 C++ 中,内联函数和 const 数据具有内部链接,除非被显式指定为 extern
  • 缺少函数主体或变量会导致 LNK2001。如果只有函数原型或 extern 声明,编译器继续运行而不会出现任何错误,但由于没有保留函数代码或变量空间,链接器将无法解析地址调用或变量引用。
  • 调用参数类型与函数声明中的参数类型不匹配的函数会导致 LNK2001。名称修饰将函数参数合并到最终的修饰函数名中。
  • 错误包含的原型导致编译器需要没有提供的函数体,这样会导致 LNK2001。如果同时具有函数 F 的类实现和非类实现,请注意 C++ 范围解析规则。
  • 在使用 C++ 时,将函数原型包含在类定义中但未能包含实现(该类的此函数的实现)会导致 LNK2001。
  • 试图从抽象基类的构造函数或析构函数调用纯虚函数会导致 LNK2001。纯虚函数没有基类实现。
  • 试图从包含静态变量声明的文件外部访问该静态变量会导致 LNK2001。根据定义,用 Static 修饰符声明的函数具有文件范围。静态变量具有相同的限制。
  • 试图在函数范围外使用用该函数声明的变量(局部变量)会导致 LNK2001。
  • 试图在多个文件中使用 C++ 全局常数会导致 LNK2001。与 C 不同,在 C++ 中全局常数具有 static 链接。若要避免此限制,可以将 const 初始化包括在头文件中,并将此头包括在 .cpp 文件中,也可以使变量成为非常数,然后使用常数引用访问它。
  • 在生成 ATL 项目的发布版本时,指示需要 CRT 启动代码。若要修复,请执行下列操作之一:
    • 将 _ATL_MIN_CRT 从预处理器定义列表中移除,以允许包括 CRT 启动代码。有关更多信息,请参见常规配置设置属性页
    • 如果可能,移除对需要 CRT 启动代码的 CRT 函数的调用,而是使用它们的 Win32 等效函数。例如,使用 lstrcmp 取代 strcmp。需要 CRT 启动代码的已知函数是一些字符串和浮点函数。

编译和链接问题

  • 项目缺少对库 (.LIB) 或对象 (.OBJ) 文件的引用。有关更多信息,请参见用作链接器输入的 .lib 文件
  • 当运行时库和 MFC 库的名称包含在对象文件模块中时使用 /NOD 会导致 LNK2001。如果使用 /NOD (/NODEFAULTLIB) 选项,这些库将不会链接到项目中,除非显式包含了它们。
  • 使用 Unicode 和 MFC 时,如果没有创建 wWinMainCRTStartup 的入口点,将在 _WinMain@16 上得到无法解析的外部对象;请使用 /ENTRY。请参见 Unicode 编程摘要

    有关更多信息,请参见下列位于 MSDN Library 中的知识库文章。在 MSDN Library 中,单击“搜索”选项卡,将文章编号或文章标题粘贴在文本框中,然后单击“列出主题”。如果按文章编号搜索,确保清除“仅搜索标题”选项。

    • Q125750   “PRB: Error LNK2001: '_WinMain@16': Unresolved External Symbol”
    • Q131204   “PRB: Wrong Project Selection Causes LNK2001 on _WinMain@16”
    • Q100639   “Unicode Support in the Microsoft Foundation Class Library”
    • Q291952    “PRB: Link Error LNK2001: Unresolved External Symbol _main”
  • 将用 /MT 编译的代码与库 LIBC.lib 链接会在 _beginthread_beginthreadex_endthread 和_endthreadex 上导致 LNK2001。
  • 链接需要多线程库的代码(任何 MFC 代码或用 /MT 编译的代码)会在 _beginthread、_beginthreadex、_endthread 和 _endthreadex 上导致 LNK2001。有关更多信息,请参见下列知识库文章:
    • Q126646“PRB: Error Msg: LNK2001 on __beginthreadex and __endthreadex”
    • Q128641“INFO: /Mx Compiler Options and the LIBC, LIBCMT, MSVCRT Libs”
    • Q166504“PRB: MFC and CRT Must Match in debug/release and static/dynamic”
  • 在用 /MD 进行编译时,因为所有的运行库现在都存放在 DLL 中,所以源中的“func”引用在对象中变为“__imp__func”引用。如果试图与静态库 LIBC.lib 或 LIBCMT.lib 链接,则将在 __imp__func 上得到 LNK2001。当不用 /MD 进行编译时,如果试图与 MSVCxx.lib 链接,则并非总是得到 LNK2001,但可能会有其他问题。
  • 将用显式或隐式 /ML 编译的代码链接到 LIBCMT.lib 时将在 _errno 上导致 LNK2001。
  • 在生成应用程序的调试版本时与发布模式库链接会导致 LNK2001。同样,使用 /Mxd 选项(/MLd/MTd 或/MDd)并/或定义 _DEBUG,然后与发布库链接将带来潜在的无法解析的外部对象(以及其他问题)。将发布模式生成与调试库链接同样会导致类似问题。
  • 将 Microsoft 库版本和编译器产品版本混合可能会有问题。新编译器版本的库可能包含早期版本的库中没有的新符号。可能需要更改搜索路径中的目录顺序,或将它们更改为指向当前版本。

    通过库文件选择下的“工具” | “选项” | “项目” | “VC++ 目录”对话框,您可以更改搜索顺序。项目的“属性页”对话框中的“链接器”文件夹可能也包含可能已过期的路径。

    当安装了新的 SDK(可能在不同的位置),但没有将搜索顺序更新为指向新位置时,可能会出现此问题。通常情况下,应将新 SDK 的 include 目录和 lib 目录的路径放在默认 Visual C++ 位置的前面。另外,包含嵌入路径的项目可能仍然指向旧路径,这些路径是有效的,但对于安装到不同位置的新版本所添加的新功能已过期。

  • 编译器供应商之间、甚至同一编译器的不同版本之间当前没有 C++ 命名标准。因此,链接用其他编译器编译的对象文件可能无法生成相同的命名方案,从而导致错误 LNK2001。
  • 在不同模块上混合内联和非内联编译选项会导致 LNK2001。如果创建 C++ 库时打开了函数内联(/Ob1 或 /Ob2),但描述函数的相应头文件的内联是关闭的(没有 inline 关键字),将发生此错误。若要防止此问题,请在要包含到其他文件中的头文件中用 inline 定义内联函数。
  • 如果使用 #pragma inline_depth 编译器指令,请确保具有设置为 2 或更大的值,并确保使用 /Ob1 或 /Ob2编译器选项。
  • 在创建纯资源 DLL 时省略 LINK 选项 /NOENTRY 将导致 LNK2001。
  • 使用不正确的 /SUBSYSTEM 或 /ENTRY 设置会导致 LNK2001。例如,如果编写基于字符的应用程序(控制台应用程序)并指定 /SUBSYSTEM:WINDOWS,您将得到无法解析的 WinMain 外部对象。有关这些选项和入口点的更多信息,请参见 /SUBSYSTEM 和 /ENTRY 链接器选项。
  • 创建的项目是一个托管 DLL,它包含的 Microsoft 中间语言代码没有链接到本机 C/C++ 库(如 CRT、ATL 或 MFC),而您是从使用静态变量的本机 C/C++ 库添加代码。若要修复,必须将该项目转换为混合模式。有关更多信息,请参见 

来自:http://www.zahui.com/html/9/35690.htm

编程摘要

若要利用 MFC 和 C 运行时对 Unicode 的支持,需要:

  • 定义 _UNICODE

    在生成程序之前定义 _UNICODE 符号。

  • 指定入口点。

    在项目的属性页对话框中“链接器”文件夹的“输出”页中,设置 wWinMainCRTStartup 的入口点符号。

  • 使用“可移植的”运行时函数和类型。

    为 Unicode 字符串处理使用正确的 C 运行时函数。可以使用 wcs 函数族,但您可能更喜欢使用完全“可移植的”(支持国际化的)_TCHAR 宏。这些宏都以 _tcs 为前缀;它们一对一地替换 str 函数族。在“运行时库参考”的国际化节中对这些函数有详细介绍。有关更多信息,请参见 TCHAR.H 中的一般文本映射

    使用支持 Unicode 中描述的 _TCHAR 和相关的可移植数据类型。

  • 正确地处理字符串。

    Visual C++ 编译器将编码的字符串解释为

    L"this is a literal string"

    指出这是 Unicode 字符的字符串。可以对文字字符使用相同的前缀。一般使用 _T 宏对字符串进行编码,因此在 Unicode 下字符串编译为 Unicode 字符串,不使用 Unicode 时字符串编译为 ANSI 字符串(包括 MBCS)。例如,不使用:

    pWnd->SetWindowText( "Hello" );

    而使用:

    pWnd->SetWindowText( _T("Hello") );

    使用已定义的 _UNICODE_T 将字符串翻译为以 L 为前缀的格式;否则 _T 将字符串翻译为不带 L 前缀的格式。

    提示   _T 宏与 _TEXT 宏相同。
  • 将字符串长度传递给函数时要小心。

    一些函数需要获取字符串的字符数;另一些函数需要获取字符串的字节数。例如,如果已定义 _UNICODE,则下列对 CArchive 对象的调用无效(str 属于 CString):

    archive.Write( str, str.GetLength( ) );    // invalid

    在 Unicode 应用程序中,由于每个字符都是双字节宽,因此长度会给出字符数但不给出正确的字节数。所以必须使用:

    archive.Write( str, str.GetLength( ) * sizeof( _TCHAR ) );    // valid

    它指定要写入的正确字节数。

    但是,MFC 成员函数是面向字符而非面向字节的,因此无需此额外的编码:

    pDC->TextOut( str, str.GetLength( ) );

    CDC::TextOut 采用字符数而非字节数。

总之,MFC 和运行时库对 Windows 2000 下的 Unicode 编程提供下列支持:

  • 除数据库类成员函数外,所有 MFC(包括 CString)函数都支持 Unicode。CString 还提供 Unicode/ANSI 转换函数。
  • 运行时库提供所有字符串处理函数的 Unicode 版本。(运行时库还提供适合 Unicode 或 MBCS 的“可移植”版本。这些版本是 _tcs 宏。)
  • TCHAR.H 提供可移植的数据类型以及翻译字符串和字符的 _T 宏。请参见 TCHAR.H 中的一般文本映射
  • 运行时库提供 main 的宽字符版本。使用 wmain 使应用程序成为“Unicode 识别”。

请参见

支持 Unicode

链接器工具错误 LNK2019

相关文章推荐

链接器工具错误 LNK2019 C++primer5第十五章程序错误的解决

编写C++第十五章15.9 文本程序再探程序时 由于初写C++程序造成许多错误 最初是出现LNK2005错误 由于重复定义头文件产生,通过查询在每个头文件前键入条件预处理指令如下 #ifndef ...

[转]vc编译链接错误--LNK2001,LNK2019,

-- LINK2001 学习VC++时经常会遇到链接错误LNK2001,该错误非常讨厌,因为对于 编程者来说,最好改的错误莫过于编译错误,而一般说来发生连接错误时, 编译都已通过。产生连接错误...

链接错误LNK2001

  • 2012年08月26日 16:01
  • 15KB
  • 下载

VC++的链接错误LNK2001

文章出处:http://blog.csdn.net/DavidHsing/article/details/2158703 在VC/MFC社区中经常看到有人问一些编译错误怎么解决的问题,很...

有关C++模板(template)的编译错误“error LNK2019: 无法解析的外部符号”的分析

转自:http://blog.csdn.net/fengyhack/article/details/39296411 按照通常的习惯,我们这样设计一个类或者结构(体): 在头文...
  • big_bit
  • big_bit
  • 2016年08月23日 11:09
  • 1699

error LNK2001: unresolved external symbol VC++链接错误详解

error LNK2001: unresolved external symbol VC++链接错误详解 学习VC++时经常会遇到链接错误LNK2001,该错误非常讨厌,因为对于编程...

链接错误LNK2001的可能几种原因

学习VC++时经常会遇到链接错误LNK2001,该错误非常讨厌,因为对于编程者来说,最好改的错误莫过于编译错误,而一般说来发生连接错误时,编译都已通过。产生连接错误的原因非常多,尤其LNK2001错误...
  • shufac
  • shufac
  • 2014年03月12日 23:06
  • 468

VC++编程时经常会遇到链接错误LNK2001

LNK2001错误,如:           Linking...           LIBCD.lib(crt0.obj) : error LNK2001: unresolved exte...

链接错误LNK2001,

 学习VC++时经常会遇到链接错误LNK2001,该错误非常讨厌,因为对于编程者来说,最好改的错误莫过于编译错误,而一般说来发生连接错误时,编译都已通过。产生连接错误的原因非常多,尤其LNK20...
  • jwy2014
  • jwy2014
  • 2014年07月25日 12:28
  • 317

LNK2001链接错误产生的原因分析和解决办法

LIBCD.lib(wincrt0.obj) : error LNK2001: unresolved external symbol _WinMain@16 Debug/smtp_5.exe : f...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:C++链接器工具错误:LNK2001, LNK2019
举报原因:
原因补充:

(最多只允许输入30个字)