什么是未定义的参考/未解析的外部符号错误？常见原因是什么？如何解决/预防？
当前回答
函数或类方法在源文件中使用内联说明符定义。
例如：-
主.cpp
#include "gum.h"
#include "foo.h"
int main()
{
gum();
foo f;
f.bar();
return 0;
}
foo.h（1）
#pragma once
struct foo {
void bar() const;
};
口香糖.h（1）
#pragma once
extern void gum();
foo.cpp（1）
#include "foo.h"
#include <iostream>
inline /* <- wrong! */ void foo::bar() const {
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
gum.cpp（1）
#include "gum.h"
#include <iostream>
inline /* <- wrong! */ void gum()
{
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
如果指定gum（类似地，foo:：bar）在其定义中是内联的，那么编译器将通过以下方式内联gum（如果它选择）：-
没有任何独特的口香糖定义，因此不发出任何符号，链接器可以通过该符号引用口香糖的定义，而是将所有对gum的调用替换为编译后的gum主体的内联副本。
因此，如果在源文件gum.cpp中内联定义gum，则编译为对象文件gum.o，其中所有对gum的调用都是内联的并且没有定义接头可以指代口香糖的符号。当你将gum.o与另一个对象文件（例如main.o）链接到程序中引用外部符号gum时，链接器无法解析这些参考文献。因此连杆失效：
编译：
g++ -c main.cpp foo.cpp gum.cpp
链接：
$ g++ -o prog main.o foo.o gum.o
main.o: In function `main':
main.cpp:(.text+0x18): undefined reference to `gum()'
main.cpp:(.text+0x24): undefined reference to `foo::bar() const'
collect2: error: ld returned 1 exit status
如果编译器可以在调用gum的每个源文件中看到它的定义，则只能将gum定义为内联。这意味着它的内联定义需要存在于包含在每个源文件中的头文件中您可以在其中调用gum。做两件事之一：
要么不内联定义
从源文件定义中删除内联说明符：
foo.cpp（2）
#include "foo.h"
#include <iostream>
void foo::bar() const {
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
gum.cpp（2）
#include "gum.h"
#include <iostream>
void gum()
{
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
重新生成：
$ g++ -c main.cpp foo.cpp gum.cpp
imk@imk-Inspiron-7559:~/develop/so/scrap1$ g++ -o prog main.o foo.o gum.o
imk@imk-Inspiron-7559:~/develop/so/scrap1$ ./prog
void gum()
void foo::bar() const
成功
或正确内联
头文件中的内联定义：
foo.h（2）
#pragma once
#include <iostream>
struct foo {
void bar() const { // In-class definition is implicitly inline
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
};
// Alternatively...
#if 0
struct foo {
void bar() const;
};
inline void foo::bar() const {
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
#endif
口香糖.h（2）
#pragma once
#include <iostream>
inline void gum() {
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
现在我们不需要foo.cpp或gum.cpp：
$ g++ -c main.cpp
$ g++ -o prog main.o
$ ./prog
void gum()
void foo::bar() const
其他回答
班级成员：
纯虚拟析构函数需要实现。
声明析构函数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允许在类内初始化所有静态常量数据成员。
函数或类方法在源文件中使用内联说明符定义。
例如：-
主.cpp
#include "gum.h"
#include "foo.h"
int main()
{
gum();
foo f;
f.bar();
return 0;
}
foo.h（1）
#pragma once
struct foo {
void bar() const;
};
口香糖.h（1）
#pragma once
extern void gum();
foo.cpp（1）
#include "foo.h"
#include <iostream>
inline /* <- wrong! */ void foo::bar() const {
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
gum.cpp（1）
#include "gum.h"
#include <iostream>
inline /* <- wrong! */ void gum()
{
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
如果指定gum（类似地，foo:：bar）在其定义中是内联的，那么编译器将通过以下方式内联gum（如果它选择）：-
没有任何独特的口香糖定义，因此不发出任何符号，链接器可以通过该符号引用口香糖的定义，而是将所有对gum的调用替换为编译后的gum主体的内联副本。
因此，如果在源文件gum.cpp中内联定义gum，则编译为对象文件gum.o，其中所有对gum的调用都是内联的并且没有定义接头可以指代口香糖的符号。当你将gum.o与另一个对象文件（例如main.o）链接到程序中引用外部符号gum时，链接器无法解析这些参考文献。因此连杆失效：
编译：
g++ -c main.cpp foo.cpp gum.cpp
链接：
$ g++ -o prog main.o foo.o gum.o
main.o: In function `main':
main.cpp:(.text+0x18): undefined reference to `gum()'
main.cpp:(.text+0x24): undefined reference to `foo::bar() const'
collect2: error: ld returned 1 exit status
如果编译器可以在调用gum的每个源文件中看到它的定义，则只能将gum定义为内联。这意味着它的内联定义需要存在于包含在每个源文件中的头文件中您可以在其中调用gum。做两件事之一：
要么不内联定义
从源文件定义中删除内联说明符：
foo.cpp（2）
#include "foo.h"
#include <iostream>
void foo::bar() const {
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
gum.cpp（2）
#include "gum.h"
#include <iostream>
void gum()
{
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
重新生成：
$ g++ -c main.cpp foo.cpp gum.cpp
imk@imk-Inspiron-7559:~/develop/so/scrap1$ g++ -o prog main.o foo.o gum.o
imk@imk-Inspiron-7559:~/develop/so/scrap1$ ./prog
void gum()
void foo::bar() const
成功
或正确内联
头文件中的内联定义：
foo.h（2）
#pragma once
#include <iostream>
struct foo {
void bar() const { // In-class definition is implicitly inline
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
};
// Alternatively...
#if 0
struct foo {
void bar() const;
};
inline void foo::bar() const {
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
#endif
口香糖.h（2）
#pragma once
#include <iostream>
inline void gum() {
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
现在我们不需要foo.cpp或gum.cpp：
$ g++ -c main.cpp
$ g++ -o prog main.o
$ ./prog
void gum()
void foo::bar() const
假设您有一个用c++编写的大型项目，它有一千个.cpp文件和一千个.h文件。假设该项目还依赖于十个静态库。假设我们在Windows上，我们在Visual Studio 20xx中构建项目。当您按Ctrl+F7 Visual Studio开始编译整个解决方案时（假设解决方案中只有一个项目）
编译的意义是什么？
Visual Studio搜索文件.vcxproj并开始编译扩展名为.cpp的每个文件。编译顺序未定义。因此，您不能假设首先编译了main.cpp文件如果.cpp文件依赖于其他.h文件来查找符号可以在.cpp文件中定义，也可以不定义如果存在一个.cpp文件，编译器在其中找不到一个符号，则编译器时间错误将引发消息symbol x not be found对于每个扩展名为.cpp的文件，都会生成一个对象文件.o，并且Visual Studio会将输出写入名为ProjectName.cpp.Clean.txt的文件中，该文件包含链接器必须处理的所有对象文件。
编译的第二步是由Linker完成的。Linker应该合并所有对象文件并最终生成输出（可能是可执行文件或库）
链接项目的步骤
分析所有对象文件，找到仅在头文件中声明的定义（例如：前面的答案中提到的类的一个方法的代码，或者初始化类内部的静态变量的事件）如果在目标文件中找不到一个符号，也会在其他库中搜索。对于将新库添加到项目的配置财产->VC++目录->库目录，您在此处指定了用于搜索库的其他文件夹，以及用于指定库名称的配置财产->链接器->输入。-如果链接器找不到您在一个.cpp中编写的符号，则会引发一个链接器时间错误，听起来可能像错误LNK2001：未解析的外部符号“void __cdecl foo（void）”（？foo@@YAXXZ）
观察
一旦链接器找到一个符号，他就不会在其他库中搜索它链接库的顺序很重要。如果Linker在一个静态库中找到一个外部符号，他会在项目的输出中包含该符号。但是，如果库是共享的（动态的），他不会在输出中包含代码（符号），但可能会发生运行时崩溃
如何解决这种错误
编译器时间错误：
确保编写的c++项目语法正确。
链接器时间错误
定义在头文件中声明的所有符号使用#pragma一次，如果编译的当前.cpp中已包含一个标头，则允许编译器不包含该标头确保外部库中不包含可能与头文件中定义的其他符号冲突的符号使用模板时，请确保在头文件中包含每个模板函数的定义，以允许编译器为任何实例化生成适当的代码。
我正在构建一个共享/动态库。它在Linux和*BSD上运行，但在Mac OS X上，完全相同的编译和链接命令会产生未解决的引用错误。有什么好处？
Mac OS X在内部与Linux和*BSD非常不同。对象/可执行文件格式为
在Linux和*BSD上，当构建共享库时，默认情况下允许未解析的引用。期望它们在加载时能够满足主可执行文件和/或其他共享库的要求。如果在加载时无法解析这些符号，则共享库将无法加载。
在Mac OS X上，构建动态库时，默认情况下不允许未解析的引用。如果希望在加载时解析引用，则需要显式启用未解析的引用。这是使用未定义的dynamic_lookup链接器标志完成的。
在构建可加载插件时，允许未解析的引用非常有用。
符号是在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"
}
