符号是在C程序中定义的，并在C++代码中使用。

函数（或变量）void foo（）是在C程序中定义的，您尝试在C++程序中使用它：

void foo();
int main()
{
    foo();
}

C++链接器希望名称被损坏，因此必须将函数声明为：

extern "C" void foo();
int main()
{
    foo();
}

等效地，函数（或变量）void foo（）不是在C程序中定义的，而是在C++中定义的但具有C链接：

extern "C" void foo();

并且尝试在C++链接的C++程序中使用它。

如果整个库包含在头文件中（并且编译为C代码）；包括以下内容：；

extern "C" {
    #include "cheader.h"
}

当包含路径不同时

当头文件及其关联的共享库（.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：改写第一节，使其更容易理解。请在下面评论，让我知道是否需要修复其他问题。谢谢

什么是“未定义的引用/未解析的外部符号”

我将尝试解释什么是“未定义的引用/未解析的外部符号”。

注意：我使用的是g++和Linux，所有示例都是针对它的

例如，我们有一些代码

// src1.cpp
void print();

static int local_var_name; // 'static' makes variable not visible for other modules
int global_var_name = 123;

int main()
{
    print();
    return 0;
}

and

// src2.cpp
extern "C" int printf (const char*, ...);

extern int global_var_name;
//extern int local_var_name;

void print ()
{
    // printf("%d%d\n", global_var_name, local_var_name);
    printf("%d\n", global_var_name);
}

生成对象文件

$ g++ -c src1.cpp -o src1.o
$ g++ -c src2.cpp -o src2.o

在汇编程序阶段之后，我们有一个对象文件，其中包含要导出的任何符号。看看这些符号

$ readelf --symbols src1.o
  Num:    Value          Size Type    Bind   Vis      Ndx Name
     5: 0000000000000000     4 OBJECT  LOCAL  DEFAULT    4 _ZL14local_var_name # [1]
     9: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    3 global_var_name     # [2]

我拒绝了输出中的一些行，因为它们无关紧要

因此，我们看到要导出的以下符号。

[1] - this is our static (local) variable (important - Bind has a type "LOCAL")
[2] - this is our global variable

src2.cpp不导出任何内容，我们没有看到它的符号

链接我们的对象文件

$ g++ src1.o src2.o -o prog

并运行它

$ ./prog
123

Linker看到导出的符号并将其链接起来

// src2.cpp
extern "C" int printf (const char*, ...);

extern int global_var_name;
extern int local_var_name;

void print ()
{
    printf("%d%d\n", global_var_name, local_var_name);
}

并重建对象文件

$ g++ -c src2.cpp -o src2.o

好的（没有错误），因为我们只构建对象文件，链接还没有完成。尝试链接

$ g++ src1.o src2.o -o prog
src2.o: In function `print()':
src2.cpp:(.text+0x6): undefined reference to `local_var_name'
collect2: error: ld returned 1 exit status

发生这种情况是因为我们的local_var_name是静态的，即它对其他模块不可见。现在更深入。获取翻译阶段输出

$ g++ -S src1.cpp -o src1.s

// src1.s
look src1.s

    .file   "src1.cpp"
    .local  _ZL14local_var_name
    .comm   _ZL14local_var_name,4,4
    .globl  global_var_name
    .data
    .align 4
    .type   global_var_name, @object
    .size   global_var_name, 4
global_var_name:
    .long   123
    .text
    .globl  main
    .type   main, @function
main:
; assembler code, not interesting for us
.LFE0:
    .size   main, .-main
    .ident  "GCC: (Ubuntu 4.8.2-19ubuntu1) 4.8.2"
    .section    .note.GNU-stack,"",@progbits

所以，我们看到local_var_name没有标签，这就是链接器找不到它的原因。但我们是黑客：），我们可以修复它。在文本编辑器中打开src1.s并更改

.local  _ZL14local_var_name
.comm   _ZL14local_var_name,4,4

to

    .globl  local_var_name
    .data
    .align 4
    .type   local_var_name, @object
    .size   local_var_name, 4
local_var_name:
    .long   456789

也就是说，你应该像下面这样

    .file   "src1.cpp"
    .globl  local_var_name
    .data
    .align 4
    .type   local_var_name, @object
    .size   local_var_name, 4
local_var_name:
    .long   456789
    .globl  global_var_name
    .align 4
    .type   global_var_name, @object
    .size   global_var_name, 4
global_var_name:
    .long   123
    .text
    .globl  main
    .type   main, @function
main:
; ...

我们已经更改了localvarname的可见性，并将其值设置为456789。尝试从中构建对象文件

$ g++ -c src1.s -o src2.o

好，请参阅readelf输出（符号）

$ readelf --symbols src1.o
8: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    3 local_var_name

现在local_var_name具有绑定GLOBAL（以前是local）

link

$ g++ src1.o src2.o -o prog

并运行它

$ ./prog 
123456789

好的，我们破解它：）

因此，当链接器在对象文件中找不到全局符号时，就会发生“未定义的引用/未解析的外部符号错误”。

如果所有其他操作都失败，请重新编译。

最近，我只需重新编译有问题的文件，就可以消除Visual Studio 2012中未解决的外部错误。当我重新构建时，错误消失了。

当两个（或多个）库具有循环依赖关系时，通常会发生这种情况。库A尝试使用B.lib中的符号，库B尝试使用A.lib中的字符。两者都不存在。当您尝试编译A时，链接步骤将失败，因为它找不到B.lib。将生成A.lib，但不会生成dll。然后编译B，这将成功并生成B.lib。重新编译A现在可以工作了，因为现在找到了B.lib。

这是每个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，因为当前搜索范围中不存在该定义。

当我们在程序中引用了对象名（类、函数、变量等），并且链接器试图在所有链接的对象文件和库中搜索它时无法找到它的定义时，就会出现“Undefined Reference”错误。

因此，当链接器找不到链接对象的定义时，它会发出“未定义引用”错误。从定义中可以清楚地看出，这种错误发生在链接过程的后期。导致“未定义引用”错误的原因多种多样。

一些可能的原因（更频繁）：

#1） 没有为对象提供定义

这是导致“未定义引用”错误的最简单原因。程序员只是忘记了定义对象。

考虑以下C++程序。这里我们只指定了函数的原型，然后在主函数中使用了它。

#include <iostream>
int func1();
int main()
{
     
    func1();
}

输出：

main.cpp:(.text+0x5): undefined reference to 'func1()'
collect2: error ld returned 1 exit status

因此，当我们编译此程序时，会发出链接器错误，该错误表示“未定义对‘func1（）’的引用”。

为了消除这个错误，我们通过提供函数func1的定义来如下更正程序。现在程序给出了适当的输出。

#include <iostream>
using namespace std;
int func1();
 
int main()
{
     
    func1();
}
int func1(){
    cout<<"hello, world!!";
}

输出：

hello, world!!

#2） 使用的对象定义错误（签名不匹配）

“未定义引用”错误的另一个原因是我们指定了错误的定义。我们在程序中使用任何对象，其定义都不同。

考虑以下C++程序。这里我们调用了func1（）。它的原型是int func1（）。但其定义与原型不符。如我们所见，函数的定义包含函数的参数。

因此，当编译程序时，由于原型和函数调用匹配，编译是成功的。但是，当链接器试图将函数调用与其定义链接时，它会发现问题并将错误作为“未定义引用”发出。

#include <iostream>
using namespace std;
int func1();
int main()
{
     
    func1();
}
int func1(int n){
    cout<<"hello, world!!";
}

输出：

main.cpp:(.text+0x5): undefined reference to 'func1()'
collect2: error ld returned 1 exit status

因此，为了防止这种错误，我们只需交叉检查程序中所有对象的定义和用法是否匹配。

#3） 对象文件未正确链接

此问题还可能导致“未定义引用”错误。在这里，我们可能有多个源文件，我们可以独立编译它们。这样做时，对象链接不正确，导致“未定义引用”。

考虑以下两个C++程序。在第一个文件中，我们使用了第二个文件中定义的“print（）”函数。当我们分别编译这些文件时，第一个文件为打印函数提供“未定义引用”，而第二个文件为主函数提供“不定义引用”。

int print();
int main()
{
    print();
}

输出：

main.cpp:(.text+0x5): undefined reference to 'print()'
collect2: error ld returned 1 exit status

int print() {
    return 42;
}

输出：

(.text+0x20): undefined reference to 'main'
collect2: error ld returned 1 exit status

解决此错误的方法是同时编译两个文件（例如，使用g++）。

除了已经讨论过的原因之外，“未定义的引用”也可能因为以下原因而发生。

#4） 错误的项目类型

当我们在visual studio等C++IDE中指定错误的项目类型，并尝试做项目不期望的事情时，我们就会得到“未定义的引用”。

#5） 没有库

如果程序员没有正确指定库路径，或者完全忘记指定它，那么我们将为程序从库中使用的所有引用获得一个“未定义引用”。

#6） 未编译从属文件

程序员必须确保我们事先编译项目的所有依赖项，以便在编译项目时，编译器找到所有依赖项并成功编译。如果缺少任何依赖项，那么编译器将给出“未定义的引用”。

除了上面讨论的原因之外，“未定义引用”错误还可能在许多其他情况下发生。但底线是程序员搞错了，为了防止这种错误，应该纠正这些错误。