C++链接器工具错误:LNK2001, LNK2019(转载)

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

无法解析的外部符号“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 的入口点,将在 _[email protected] 上得到无法解析的外部对象;请使用 /ENTRY。请参见 Unicode 编程摘要

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

    • Q125750   “PRB: Error LNK2001: ‘[email protected]‘: Unresolved External Symbol”
    • Q131204   “PRB: Wrong Project Selection Causes LNK2001 on [email protected]”
    • 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

时间: 2024-10-05 16:49:05

C++链接器工具错误:LNK2001, LNK2019(转载)的相关文章

链接器工具错误 LNK2011

问题描述: 使用visual studio 2015编译apr-iconv失败,提示"链接器工具错误 LNK2011:未链接预编译对象:映像可能不能运行"错误. 原因分析: MSDN关于该错误描述如下(https://msdn.microsoft.com/zh-cn/library/3ay26wa2.aspx): 如果使用预编译头,LINK 要求必须链接所有与预编译头一起创建的对象文件. 如果您有用来生成用于其他源文件的预编译头的源文件,现在必须包括与预编译头一起创建的对象文件.例如,

分离式编译时 链接器工具错误 (一个变量被定义一次或多次)

在编写程序时,将类中的函数成员的声明和定义分开,在头文件(.h)中进行声明,在源文件(.cpp)中进行定义 以及具体功能的实现.达到分离式编译的效果,提高代码的可读性. 自己在编写是程序时,程序显示没有错误,但是在生成时,产生了链接器工具错误LNK2005 的错误提示.这个错误 也会导致另外一个错误LNK1169 找到一个或多个多重定义的符号. 原因是在.cpp 文件内定义函数时加上了 inline  修饰符将函数声明成了内联函数. 内联函数用于优化规模较小,流程直接,频繁调用的函数.通常是将内

VS中出现“链接器工具错误,XXX工具模块对于SAFESEH映像是不安全的”的解决方法

1.“调试”菜单->“属性”->“配置属性”->“链接器”->“命令行” 2.在“其它选项”的输入框里输入 /SAFESEH:NO ,点击“应用”

笔记:LNK2001不代表链接器真的需要链接相关符号

环境:VS2008 我们都知道,链接器在生成可执行程序时,会忽略那些没有用到的符号.但是昨天遇到一个链接问题,看起来与这条基本策略并不相符.首先看一个静态链接库的结构: lib | |---------------------| a.cpp b.cpp | | |-------| |-----------| fun1 fun2 fun3 fun4 | ↑___________| ↓ GetModuleFileNameEx(psapi.lib) 这个库里只存在两个依赖:b.cpp中的fun3依赖于

【嵌入式开发】 嵌入式开发工具简介 (裸板调试示例 | 交叉工具链 | Makefile | 链接器脚本 | eclipse JLink 调试环境)

作者 : 韩曙亮 博客地址 : http://blog.csdn.net/shulianghan/article/details/42239705  参考博客 : [嵌入式开发]嵌入式 开发环境 (远程登录 | 文件共享 | NFS TFTP 服务器 | 串口连接 | Win8.1 + RedHat Enterprise 6.3 + Vmware11) 开发环境 : -- 操作系统 : Vmware11 + RedHat6.3 企业版 + Win8.1; -- 硬件 : OK-6410-A 开发

(转载)你好,C++(4)2.1.3 我的父亲母亲:编译器和链接器 2.1.4 C++程序执行背后的故事

你好,C++(4)2.1.3 我的父亲母亲:编译器和链接器 2.1.4 C++程序执行背后的故事 2.1.3  我的父亲母亲:编译器和链接器 从表面上看,我是由Visual Studio创建的,而实际上,真正负责编译源代码创建生成可执行程序HelloWorld.exe的却是Visual Studio中集成的C++编译器cl.exe和链接器link.exe.他们二老,才是我的亲生爹妈. 为了便于人们的编写.阅读和维护,我们的源文件是使用C++这种人们可以理解的高级程序设计语言编写的.然而,计算机却

链接器link.exe 编译器cl.exe 资源编译器rc.exe

原文地址:https://blog.csdn.net/biggbang/article/details/24433065 1.cl.exe文件是Visual C\C++的编译器,它将程序源代码文件编译为obj文件. 2.rc.exe文件是资源编译器.工程项目中的.rc文件中包含了对程序中所使用资源(菜单.图标等)的描述.rc.exe将.rc格式的文件编译为.res文件,供链接器链接到可执行文件中. 3.link.exe是Windows平台的链接器,它将cl.exe编译生成的obj文件,资源编译器

链接器

作者:左少华 时间:2015-05-24 转载请注明出处: http://blog.csdn.net/shaohuazuo/article/details/45957971 连接器的功能 链接器是将各种代码和数据部分收集起来并合成一个单一文件的过程, 这个文件可以被加载到存储器中执行. 链接器的执行时机 可以执行于编译时,也就是在源代码被翻译成机器代码的时候. 可以执行于加载时,也就是程序被加载器加载到存储器,并执行时. 可以执行于运行时,由应用程序来执行. 链接是通过链接器程序自动执行的. 为

自己动手写编译器、链接器目录结构

自序 8第1章 引言 101.1 Hello World编译过程分析 101.1.1 Hello World程序源文件 101.1.2 词法分析 111.1.3 语法分析 121.1.4 语义分析 131.1.5 链接器 141.2 SCC编译器简介 161.2.1 SCC编译器架构 161.2.2 SCC编译器开发环境 171.2.3 SCC编译器运行环境 18第2章 文法知识 202.1 语言概述 202.2 形式语言 212.2.1 字母表和符号串 212.2.2 文法与语言的形式定义 2