需要考虑的一些拼写错误：（我作为初学者经常遇到）

如果您使用的是类：请检查您是否没有在定义函数的cpp文件中的函数名之前忘记“classname:：”。如果使用forward声明：请确保声明正确的类型。例如：如果要转发声明“结构”，请使用“结构”而不是“类”。

这是每个VC++程序员一再看到的最令人困惑的错误消息之一。让我们先把事情弄清楚。

A.什么是符号？简而言之，符号就是名称。它可以是变量名、函数名、类名、typedef名，或者除了那些属于C++语言的名称和符号之外的任何名称和符号。它由用户定义或由依赖库（另一个用户定义的）引入。

B.什么是外部的？在VC++中，每个源文件（.cpp、.c等）都被视为一个翻译单元，编译器一次编译一个单元，并为当前翻译单元生成一个目标文件（.obj）。（请注意，此源文件包含的每个头文件都将被预处理，并将被视为此翻译单元的一部分）翻译单元中的所有内容都被视为内部内容，其他所有内容都视为外部内容。在C++中，可以使用关键字extern、__declspec（dllimport）等引用外部符号。

C.什么是“决心”？Resolve是一个链接时间术语。在链接时，链接器尝试为对象文件中无法在内部找到其定义的每个符号找到外部定义。此搜索过程的范围包括：

编译时生成的所有对象文件显式或隐式的所有库（.lib）指定为此生成应用程序的附加依赖项。

此搜索过程称为解析。

D.最后，为什么是未解决的外部符号？如果链接器找不到内部没有定义的符号的外部定义，则会报告“未解决的外部符号”错误。

E.LNK2019的可能原因：未解决的外部符号错误。我们已经知道，此错误是由于链接器未能找到外部符号的定义所致，可能的原因如下：

定义已存在

例如，如果我们在.cpp中定义了一个名为foo的函数：

int foo()
{
    return 0;
}

在b.cpp中，我们希望调用函数foo，因此我们添加

void foo();

要声明函数foo（），并在另一个函数体中调用它，请使用bar（）：

void bar()
{
    foo();
}

现在，当您构建此代码时，您将收到一个LNK2019错误，抱怨foo是一个未解析的符号。在本例中，我们知道foo（）的定义在.cpp中，但与我们调用的定义不同（返回值不同）。这就是定义存在的情况。

定义不存在

如果我们想调用库中的某些函数，但导入库没有添加到项目设置的附加依赖项列表中（设置自：项目|财产|配置财产|链接器|输入|附加依赖项）。现在链接器将报告LNK2019，因为当前搜索范围中不存在该定义。

未能链接到适当的库/对象文件或编译实现文件

通常，每个翻译单元都会生成一个包含该翻译单元中定义的符号定义的对象文件。要使用这些符号，必须链接这些对象文件。

在gcc下，您可以指定要在命令行中链接在一起的所有对象文件，或者一起编译实现文件。

g++ -o test objectFile1.o objectFile2.o -lLibraryName

-我。。。必须位于任何.o/.c/.cpp文件的右侧。

这里的libraryName只是库的裸名，没有特定于平台的添加。例如，在Linux上，库文件通常被称为libfoo.So，但您只能编写-lfo。在Windows上，相同的文件可能被称为foo.lib，但您将使用相同的参数。您可能需要添加目录，在该目录中可以使用-Lûdirectory›找到这些文件。确保不要在-l或-l后面写空格。

对于Xcode：添加用户标题搜索路径->添加库搜索路径->将实际的库引用拖放到项目文件夹中。

在MSVS下，添加到项目中的文件会自动将其对象文件链接在一起，并生成一个lib文件（常见用法）。要在单独的项目中使用符号，您需要需要在项目设置中包含lib文件。这是在项目财产的链接器部分的Input->Additional Dependencies中完成的。（指向lib文件的路径应为在Linker->General->Additional Library Directories中添加）当使用随lib文件提供的第三方库时，失败通常会导致错误。

还可能发生忘记将文件添加到编译中的情况，在这种情况下，不会生成对象文件。在gcc中，您可以将文件添加到命令行。在MSVS中，将文件添加到项目将使其自动编译（尽管文件可以手动从构建中单独排除）。

在Windows编程中，未链接必要库的标志是未解析符号的名称以__imp_开头。在文档中查找函数的名称，它应该指出您需要使用哪个库。例如，MSDN将信息放在名为“库”的部分中每个函数底部的框中。

指定相互依赖的链接库的顺序是错误的。

如果库相互依赖，则库的链接顺序也很重要。通常，如果库A依赖于库B，那么在链接器标志中，libA必须出现在libB之前。

例如：

// B.h
#ifndef B_H
#define B_H

struct B {
    B(int);
    int x;
};

#endif

// B.cpp
#include "B.h"
B::B(int xx) : x(xx) {}

// A.h
#include "B.h"

struct A {
    A(int x);
    B b;
};

// A.cpp
#include "A.h"

A::A(int x) : b(x) {}

// main.cpp
#include "A.h"

int main() {
    A a(5);
    return 0;
};

创建库：

$ g++ -c A.cpp
$ g++ -c B.cpp
$ ar rvs libA.a A.o 
ar: creating libA.a
a - A.o
$ ar rvs libB.a B.o 
ar: creating libB.a
a - B.o

编译：

$ g++ main.cpp -L. -lB -lA
./libA.a(A.o): In function `A::A(int)':
A.cpp:(.text+0x1c): undefined reference to `B::B(int)'
collect2: error: ld returned 1 exit status
$ g++ main.cpp -L. -lA -lB
$ ./a.out

再说一遍，顺序很重要！

常量变量声明/定义中缺少“extern”（仅限C++）

对于来自C语言的人来说，在C++中，全局常量变量具有内部（或静态）联系可能是一件令人惊讶的事情。在C中情况并非如此，因为所有全局变量都是隐式外部变量（即，当缺少静态关键字时）。

例子：

// file1.cpp
const int test = 5;    // in C++ same as "static const int test = 5"
int test2 = 5;

// file2.cpp
extern const int test;
extern int test2;

void foo()
{
 int x = test;   // linker error in C++ , no error in C
 int y = test2;  // no problem
}

正确的做法是使用头文件并将其包含在file2.cpp和file1.cpp中

extern const int test;
extern int test2;

或者，可以使用显式extern在file1.cpp中声明const变量

当包含路径不同时

当头文件及其关联的共享库（.lib文件）不同步时，可能会发生链接器错误。让我解释一下。

链接器是如何工作的？链接器通过比较函数声明（在头中声明）和函数定义（在共享库中）的签名来匹配它们。如果链接器找不到完全匹配的函数定义，则可能会出现链接器错误。

即使声明和定义似乎匹配，仍然可能出现链接器错误吗？对它们在源代码中看起来可能相同，但这实际上取决于编译器所看到的内容。基本上，你可能会遇到这样的情况：

// header1.h
typedef int Number;
void foo(Number);

// header2.h
typedef float Number;
void foo(Number); // this only looks the same lexically

注意，即使两个函数声明在源代码中看起来相同，但根据编译器的不同，它们确实不同。

你可能会问，一个人在这样的情况下是如何结束的？当然包括路径！如果在编译共享库时，include路径指向header1.h，而您最终在自己的程序中使用了header2.h，那么您将无法理解发生了什么（双关语）。

下面将解释这在现实世界中如何发生的一个示例。

通过示例进一步阐述

我有两个项目：graphics.lib和main.exe。两个项目都依赖common_math.h。假设库导出以下函数：

// graphics.lib    
#include "common_math.h" 
   
void draw(vec3 p) { ... } // vec3 comes from common_math.h

然后，您继续将库包含在您自己的项目中。

// main.exe
#include "other/common_math.h"
#include "graphics.h"

int main() {
    draw(...);
}

繁荣你得到了一个链接器错误，你不知道它为什么会失败。原因是公共库使用相同includecommon_math.h的不同版本（我在本例中通过包含不同的路径来说明这一点，但可能并不总是那么明显。可能编译器设置中的包含路径不同）。

注意，在这个例子中，链接器会告诉你它找不到draw（），而实际上你知道它显然是由库导出的。你可以花几个小时挠头，想知道出了什么问题。问题是，链接器看到的签名不同，因为参数类型略有不同。在本例中，就编译器而言，vec3在两个项目中都是不同的类型。这可能是因为它们来自两个稍微不同的包含文件（可能包含文件来自库的两个不同版本）。

调试链接器

如果您正在使用Visual Studio，DUMPBIN是您的朋友。我相信其他编译器也有类似的工具。

过程如下：

注意链接器错误中给出的奇怪的损坏名称。（例如。draw@graphics@XYZ）。将库中导出的符号转储到文本文件中。搜索导出的感兴趣符号，并注意损坏的名称不同。请注意，为什么被弄乱的名字最终会不同。您将能够看到参数类型不同，即使它们在源代码中看起来相同。它们不同的原因。在上面给出的示例中，它们是不同的，因为包含文件不同。

[1] 我所说的项目是指一组链接在一起以生成库或可执行文件的源文件。

编辑1：改写第一节，使其更容易理解。请在下面评论，让我知道是否需要修复其他问题。谢谢