因为当涉及到链接器错误时，人们似乎都在关注这个问题，所以我将在这里添加这个问题。

GCC 5.2.0中出现链接器错误的一个可能原因是现在默认选择了新的libstdc++库ABI。

如果您在std:：__cxx11命名空间或标记[abi:cx11]中获得了有关符号未定义引用的链接器错误，则可能表明您正在尝试将使用_GLIBCXX_USE_cxx11_abi宏的不同值编译的对象文件链接在一起。这通常发生在链接到使用旧版本GCC编译的第三方库时。如果无法使用新的ABI重建第三方库，则需要使用旧的ABI重新编译代码。

因此，如果在5.1.0之后切换到GCC时突然出现链接器错误，这将是一件值得检查的事情。

UNICODE定义不一致

Windows UNICODE构建时，TCHAR等被定义为wchar_t等。如果不使用UNICODE进行构建，则TCHAR被定义为char等。这些UNICODE和_UNICODE定义会影响所有“t”字符串类型；LPTSTR、LPCTSTR及其麋鹿。

构建一个定义了UNICODE的库，并试图将其链接到未定义UNICODE项目中，将导致链接器错误，因为TCHAR的定义将不匹配；char与wchar_t。

错误通常包括一个带有char或wchar_t派生类型的值的函数，这些类型也可能包括std:：basic_string<>等。浏览代码中受影响的函数时，通常会引用TCHAR或std:：basic_string<TCHAR>等。这是一个信号，表明代码最初用于UNICODE和多字节字符（或“窄”）构建。

要更正此问题，请使用UNICODE（和_UNICODE）的一致定义构建所有必需的库和项目。

这可以通过以下两种方式实现：；#定义UNICODE#定义UNICODE或在项目设置中；项目财产>常规>项目默认值>字符集或在命令行上；/DUNICODE/D-UNICODE

如果不打算使用UNICODE，请确保未设置定义，和/或在项目中使用了多字符设置，并始终应用。

不要忘记在“发布”和“调试”版本之间保持一致。

编译C++程序分几个步骤进行，如2.2所述（Keith Thompson作为参考）：

翻译语法规则之间的优先顺序由以下阶段规定[参见脚注]。物理源文件字符以实现定义的方式映射到基本源字符集（为行尾指示符引入新的行尾字符）如果必需的[剪]将删除紧跟着换行符的反斜杠字符（\）的每个实例，将物理源行拼接到形成逻辑源线。[剪]源文件被分解为预处理标记（2.5）和空白字符序列（包括注释）。[剪]执行预处理指令，展开宏调用，并执行_Pragma一元运算符表达式。[剪]字符文本或字符串文本中的每个源字符集成员，以及每个转义序列和通用字符名在字符文本或非原始字符串文本中执行字符集的对应成员；[剪]连接相邻的字符串文字标记。分隔标记的空白字符不再有效。每个预处理令牌都转换为一个令牌。（2.7）对生成的令牌进行语法和语义分析翻译为翻译单元。[剪]翻译的翻译单元和实例化单元组合如下：[SNIP]解析所有外部实体引用。链接库组件以满足对未在中定义的实体的外部引用当前翻译。所有这样的转换器输出都被收集到包含执行所需信息的程序映像执行环境。（强调矿井）[脚注]尽管在实践中不同的阶段可能会被合并在一起，但实现必须表现得好像这些单独的阶段发生了一样。

指定的错误发生在编译的最后阶段，通常称为链接。这基本上意味着你把一堆实现文件编译成了对象文件或库，现在你想让它们一起工作。

假设您在.cpp中定义了符号a。现在，b.cpp声明了该符号并使用了它。在链接之前，它只是假设该符号是在某个地方定义的，但它并不在乎在哪里。链接阶段负责查找符号并将其正确链接到b.cpp（实际上，链接到使用它的对象或库）。

如果您使用的是Microsoft Visual Studio，您将看到项目生成.lib文件。其中包含导出符号表和导入符号表。导入的符号将根据链接的库进行解析，导出的符号将提供给使用该.lib的库（如果有）。

其他编译器/平台也存在类似的机制。

常见的错误消息包括错误LNK2001、错误LNK1120、错误LNK2019（适用于Microsoft Visual Studio）和未定义的对GCC symbolName的引用。

代码：

struct X
{
   virtual void foo();
};
struct Y : X
{
   void foo() {}
};
struct A
{
   virtual ~A() = 0;
};
struct B: A
{
   virtual ~B(){}
};
extern int x;
void foo();
int main()
{
   x = 0;
   foo();
   Y y;
   B b;
}

将使用GCC生成以下错误：

/home/AbiSfw/ccvvuHoX.o: In function `main':
prog.cpp:(.text+0x10): undefined reference to `x'
prog.cpp:(.text+0x19): undefined reference to `foo()'
prog.cpp:(.text+0x2d): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o: In function `B::~B()':
prog.cpp:(.text._ZN1BD1Ev[B::~B()]+0xb): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o: In function `B::~B()':
prog.cpp:(.text._ZN1BD0Ev[B::~B()]+0x12): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o:(.rodata._ZTI1Y[typeinfo for Y]+0x8): undefined reference to `typeinfo for X'
/home/AbiSfw/ccvvuHoX.o:(.rodata._ZTI1B[typeinfo for B]+0x8): undefined reference to `typeinfo for A'
collect2: ld returned 1 exit status

以及Microsoft Visual Studio中的类似错误：

1>test2.obj : error LNK2001: unresolved external symbol "void __cdecl foo(void)" (?foo@@YAXXZ)
1>test2.obj : error LNK2001: unresolved external symbol "int x" (?x@@3HA)
1>test2.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall A::~A(void)" (??1A@@UAE@XZ)
1>test2.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall X::foo(void)" (?foo@X@@UAEXXZ)
1>...\test2.exe : fatal error LNK1120: 4 unresolved externals

常见原因包括：

未能链接到适当的库/对象文件或编译实现文件已声明和未定义的变量或函数。类类型成员的常见问题模板实现不可见。符号是在C程序中定义的，并在C++代码中使用。跨模块.dll错误地导入/导出方法/类。（特定于MSVS）循环库依赖关系对的未定义引用`WinMain@16'相互依赖的库顺序多个同名源文件使用#pragma（Microsoft Visual Studio）时键入错误或不包含.lib扩展名模板好友问题UNICODE定义不一致常量变量声明/定义中缺少“extern”（仅限C++）未为多文件项目配置Visual Studio代码在Mac OS X上构建dylib时出错，但在其他Unix-y系统上也可以

当您使用错误的编译器构建程序时

如果您使用的是gcc或clang编译器套件，则应根据所使用的语言使用正确的编译器驱动程序。使用g++或clang++编译和链接C++程序。改用gcc或clang将导致对C++标准库符号的引用未定义。例子：

$ gcc -o test test.cpp    
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccPv7MvI.o: warning: relocation against `_ZSt4cout' in read-only section `.text' 
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccPv7MvI.o: in function `main': test.cpp:(.text+0xe): undefined reference to `std::cout' 
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: test.cpp:(.text+0x13): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)' 
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccPv7MvI.o: in function `__static_initialization_and_destruction_0(int, int)': 
test.cpp:(.text+0x43): undefined reference to `std::ios_base::Init::Init()' 
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: test.cpp:(.text+0x58): undefined reference to `std::ios_base::Init::~Init()' 
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating DT_TEXTREL in a PIE 
collect2: error: ld returned 1 exit status

当我们在程序中引用了对象名（类、函数、变量等），并且链接器试图在所有链接的对象文件和库中搜索它时无法找到它的定义时，就会出现“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） 未编译从属文件

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

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

班级成员：

纯虚拟析构函数需要实现。

声明析构函数pure仍然需要定义它（与常规函数不同）：

struct X
{
    virtual ~X() = 0;
};
struct Y : X
{
    ~Y() {}
};
int main()
{
    Y y;
}
//X::~X(){} //uncomment this line for successful definition

这是因为在隐式销毁对象时调用基类析构函数，因此需要定义。

虚拟方法必须实现或定义为纯方法。

这类似于没有定义的非虚拟方法，增加了如下推理：纯声明会生成一个虚拟vtable，您可能会在不使用函数的情况下得到链接器错误：

struct X
{
    virtual void foo();
};
struct Y : X
{
   void foo() {}
};
int main()
{
   Y y; //linker error although there was no call to X::foo
}

要使其工作，请将X:：foo（）声明为纯：

struct X
{
    virtual void foo() = 0;
};

非虚拟类成员

即使未明确使用，也需要定义某些成员：

struct A
{ 
    ~A();
};

以下内容将产生错误：

A a;      //destructor undefined

实现可以在类定义本身中内联：

struct A
{ 
    ~A() {}
};

或外部：

A::~A() {}

如果实现在类定义之外，但在头中，则必须将方法标记为内联，以防止多重定义。

如果使用，则需要定义所有使用的成员方法。

一个常见的错误是忘记限定名称：

struct A
{
   void foo();
};

void foo() {}

int main()
{
   A a;
   a.foo();
}

定义应为

void A::foo() {}

静态数据成员必须在类外部的单个转换单元中定义：

struct X
{
    static int x;
};
int main()
{
    int x = X::x;
}
//int X::x; //uncomment this line to define X::x

可以为类定义中的整型或枚举类型的静态常量数据成员提供初始值设定项；然而，odr使用这个成员仍然需要如上所述的命名空间范围定义。C++11允许在类内初始化所有静态常量数据成员。