VS编译器：LNK链接错误汇总：LNK2001 / LNK2005 / LNK2019 / LNK1120

VS编译期间遇到各式各样的链接LNK错误，作一汇总:

LNK1120: 1 个无法解析的外部命令

这个问题的原因是有头文件，但是找不到实现。
有两个原因：1.只包含了头文件，只有这个函数的声明，没有包含这个函数的实现(实现一般放在cpp文件中的)。所以只能通过编译，连接不成功。
2.另一个原因是函数的声明和实现都放在头文件中了，一般要把声明放头文件中，实现放在cpp文件中。这样每个#include该头文件的文件都会有一份该函数的实现，连接的时候，连接器不知道连接哪一个实现，于是报错。

LNK2001: 无法解析的外部符号的几种情况
一般来说，我们引用第三方库时，需要进行指定依赖项配置，若没有进行相关配置，则编译器会出现“LNK2001: 无法解析的外部符号”错误。

这个是最常见的问题，具体步骤：
项目、属性、链接器、常规、附加库目录：填写附加依赖库所在目录分号间隔多项
项目、属性、链接器、输入、附加依赖项：填写附加依赖库的名字.lib 空格或分号间隔多项

若已经按照上述步骤进行配置，但编译器还是报错，可能情况如下：

1.编译lib库和引用lib库平台不一致

lib库采用的编译平台和引用该lib的工程的编译平不兼容导致的。比如项目采用vs2008编译，而该lib是用2010编译的，亦或者项目采用vs2015平台，而lib是vs2008编译的也可能导致链接失败。

2.编译lib库和引用lib库选项不一致情况

1、一个lib库采用“多线程 DLL (/MD)”配置，而另外一个项目采用“多线程(/MT)”编译配置
2、一个lib库采用“使用 Unicode 字符集”配置，而另外一个项目采用“使用多字节字符集”编译配置
3、一个lib库采用选择“release 版本 ”配置，而另外一个项目采用选择 “debug 版本 ”编译配置
4、一个lib库采用“wind32平台 ”配置，而另外一个项目采用“wind64平台 ”编译配置

3.没有添加指定预编译宏

在使用curl静态库时，却遇到了编译链接错误：
1>testcurl.obj : error LNK2001: unresolved external symbol __imp__curl_easy_init
1>testcurl.obj : error LNK2001: unresolved external symbol __imp__curl_easy_setopt
1>testcurl.obj : error LNK2001: unresolved external symbol __imp__curl_easy_perform
1>testcurl.obj : error LNK2001: unresolved external symbol __imp__curl_easy_cleanup

解决方法是，在自己的项目属性中添加一个预编译宏，CURL_STATICLIB，

为了避免遇到以上问题建议：

1、引用第三方库时，确认lib库是否使用相同编译平台
2、确认编译选项是否一致。比如运行时库和字符集
3、若需要则添加指定编译宏
4、添加附加库目录和附加依赖项

LNK2005：已经在.obj中定义
比如：head1.h中定义了全局变量int a = 10;

在一个类的头文件class.h中包含了头文件head1.h如：include “head1.h”

于是我将include "head1.h"从class.h中移到了class.cpp中，问题解决。

分析，因为class.cpp中include “class.h”，class.h中include “head1.h”，发现没，会造成head1.h的重复引用，虽然用pragma等也无法解决，移到class.cpp中，它生成obj文件时，只引用一次，问题解决。

LNK2019
导致LNK2019的常见问题：

（1）未链接的对象文件或包含符号定义的库

（2）符号声明的拼写不与符号的定义相同

（3）使用了函数，但类型或参数数目不匹配函数定义

（4）声明但未定义的函数或变量

（5) 调用约定是函数声明和函数定义之间的差异

（6）符号定义在c文件中，但未使用extern C在c++文件中声明

（7）符号定义为静态，并随后被外部文件引用

（8）未定义类的静态成员

（9) 生成依赖项仅定义为解决方案中项目依赖项

（10）第三方库问题和Vcpkg

vcpkg 是一种命令行包管理器，可极大简化 Windows 上第三方库的购置与安装。如果项目要使用第三方库，建议通过 vcpkg 来安装它们。 vcpkg 同时支持开源和专有库。已测试 vcpkg 公共目录中所有库与 Visual Studio 2015 及 Visual Studio 2017 的兼容性。通过 vcpkg 可以消除或最大程度减少不匹配二进制文件的存在风险及它可能造成的问题。

常见修改方法：

a.改为静态CRT

Configuration Properties->C/C+±>Code Generation->Runtime Library->
debug版选/MD

release版选/MT

b.严重性代码说明项目文件行禁止显示状态

错误 LNK2019 无法解析的外部符号 WinMain，该符号在函数 “int __cdecl __scrt_common_main_seh(void)” (?__scrt_common_main_seh@@YAHXZ)中被引用。

WinMain是Win32项目的入口，所以把应用程序改为控制台类型

考虑可能的原因:
[0]出现无法解析可能是因为lib文件不正确,比如64位的编译配置,结果使用的是32位的lib包.
[1]只写了类声明，但还没有写实现类,造成调用时无法解析
[2]声明和定义没有统一，造成链接不一致，无法解析
[3]没有在项目属性页的链接器的命令行选项加入相应的类包。
[4]没有在c++包含目录和库目录加入相应的类包路径(.h和.lib)，.h一般在src文件夹中，.lib一般在lib文件夹
[5]在测试工程中被测文件目录可能需要包含被测类的cpp定义文件
[6]ICE接口测试时，无法解析可能因为被测文件没有包含进相关的cpp文件，另外，在TestSuite_ProjectRun.h文件中需要包含IProjectRun.h头文件，及相关的头文件(举例)。

[7]import相关的无法解析内容，解决办法是在链接器的依赖项中加入相应的动态库

[8]出现如下错误的原因一般是动态库没有包进来。__imp
ProjectRun.obj : error LNK2019: 无法解析的外部符号 __imp__StartHistoryLocalModule，该符号在函数 “protected: virtual int __thiscall HiRTDB::CProjectRun::DoStart(void)” (?DoStart@CProjectRun@HiRTDB@@MAEHXZ) 中被引用

[9]error LNK2001: 无法解析的外部符号 __imp___CrtDbgReportW
工程属性，C/C++,代码生成，运行时库选择MDd,

[9]无法解析的外部符号"__declspec(dllimport) public: int __thiscall HiRTDB::CTagTree::GetObjectA(int,struct HiRTDB::SBaseReadProps const &,struct HiRTDB::SBaseReadValues &)" (_imp?GetObjectA@CTagTree@HiRTDB@@QAEHHABUSBaseReadProps@2@AAUSBaseReadValues@2@@Z)，该符号在函数"public: int __thiscall HiRTDB::CStringImpl::Get(int,struct HiRTDB::SStringReadProps const &,struct HiRTDB::SStringReadValues &)" (?Get@CStringImpl@HiRTDB@@QAEHHABUSStringReadProps@2@AAUSStringReadValues@2@@Z) 中被引用

原因可能是工程配置文件中有多余选项，请参考其他模块的配置选项，不要有多余配置。

[10]在项目属性\链接器\输入\附加依赖项中没有添加***.lib