什么是未定义的参考/未解析的外部符号错误？常见原因是什么？如何解决/预防？
当前回答
函数或类方法在源文件中使用内联说明符定义。
例如：-
主.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程序中定义的，并在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"
}
链接在引用库的对象文件之前使用库
您正在尝试编译程序并将其与GCC工具链链接。链接指定了所有必要的库和库搜索路径如果libfoo依赖于libbar，那么链接会正确地将libfoo放在libbar之前。链接失败，对某些错误的引用未定义。但是所有未定义的东西都在你的头文件中声明#并且实际上是在您链接的库中定义的。
示例在C中。它们也可以是C++
一个涉及您自己构建的静态库的最小示例
my_lib.c文件
#include "my_lib.h"
#include <stdio.h>
void hw(void)
{
puts("Hello World");
}
my_lib.h
#ifndef MY_LIB_H
#define MT_LIB_H
extern void hw(void);
#endif
例如1.c
#include <my_lib.h>
int main()
{
hw();
return 0;
}
构建静态库：
$ gcc -c -o my_lib.o my_lib.c
$ ar rcs libmy_lib.a my_lib.o
编译程序：
$ gcc -I. -c -o eg1.o eg1.c
尝试将其与libmy_lib.a链接，但失败：
$ gcc -o eg1 -L. -lmy_lib eg1.o
eg1.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status
如果您在一个步骤中编译和链接，则会得到相同的结果，例如：
$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
/tmp/ccQk1tvs.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status
一个涉及共享系统库的最小示例，即压缩库libz
例如2.c
#include <zlib.h>
#include <stdio.h>
int main()
{
printf("%s\n",zlibVersion());
return 0;
}
编译程序：
$ gcc -c -o eg2.o eg2.c
尝试将程序与libz链接并失败：
$ gcc -o eg2 -lz eg2.o
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status
如果您一次编译并链接：
$ gcc -o eg2 -I. -lz eg2.c
/tmp/ccxCiGn7.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status
示例2的一个变体涉及pkg配置：
$ gcc -o eg2 $(pkg-config --libs zlib) eg2.o
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
你做错了什么？
在要链接的对象文件和库序列中程序，您将库放在引用的对象文件之前他们您需要将库放在引用对他们来说。
正确链接示例1：
$ gcc -o eg1 eg1.o -L. -lmy_lib
成功：
$ ./eg1
Hello World
正确链接示例2：
$ gcc -o eg2 eg2.o -lz
成功：
$ ./eg2
1.2.8
正确链接示例2 pkg配置变体：
$ gcc -o eg2 eg2.o $(pkg-config --libs zlib)
$ ./eg2
1.2.8
解释
从这里开始，阅读是可选的。
默认情况下，GCC在您的发行版上生成的链接命令，在中从左到右使用链接中的文件命令行序列。当它发现一个文件引用了某个并且不包含其定义，to将搜索定义在更右边的文件中。如果它最终找到了定义解析引用。如果任何引用在结束时仍未解决，链接失败：链接器没有向后搜索。
首先，示例1，使用静态库my_lib.a
静态库是对象文件的索引存档。当链接器在链接序列中找到-lmy-lib，并指出这是指到静态库/libmy_lib.a，它想知道您的程序是否需要libmy_lib.a中的任何对象文件。
libmy_lib.a中只有一个对象文件，即my_lib.o，并且只定义了一个对象在my_lib.o中，即函数hw。
链接器将决定您的程序需要my_lib.o，如果并且仅当它已经知道您的程序在一个或多个对象文件中引用hw添加到程序中，并且没有添加任何对象文件包含hw的定义。
如果这是真的，那么链接器将从库中提取my_lib.o的副本，并将其添加到您的程序中。然后，您的程序包含hw的定义，因此其对hw的引用被解析。
当您尝试链接程序时，如：
$ gcc -o eg1 -L. -lmy_lib eg1.o
链接器在看到时没有将eg1.o添加到程序中-lmy_库。因为在这一点上，它还没有看到eg1.o。您的程序尚未引用hw:it根本没有做任何引用，因为它做的所有引用在eg1.o中。
因此，链接器不会将my_lib.o添加到程序中，并且没有其他内容用于libmy_lib.a。
接下来，它找到eg1.o，并将其添加到程序中。中的对象文件链接序列总是添加到程序中。现在，该程序使对hw的引用，并且不包含hw的定义；但是链接序列中没有任何内容可以提供缺失释义对hw的引用最终无法解析，链接失败。
第二，示例2，使用共享库libz
共享库不是对象文件或类似文件的存档更像是一个没有主功能的程序而是公开它定义的多个其他符号程序可以在运行时使用它们。
今天，许多Linux发行版配置其GCC工具链，以便其语言驱动程序（GCC、g++、gfortran等）指示系统链接器（ld）根据需要链接共享库。你有一个这样的发行版。
这意味着当链接器在链接序列中找到-lz，并发现这是指到共享库（例如）/usr/lib/x86_64-linux-gnu/libz，它想知道它添加到程序中的任何尚未定义的引用是否具有libz导出的定义
如果这是真的，那么链接器将不会从libz和将它们添加到您的程序中；相反，它只会修改程序的代码从而：-
在运行时，系统程序加载器会将libz的副本加载到无论何时加载程序的副本，都可以执行与程序相同的过程。在运行时，每当程序引用libz，该引用使用中libz副本导出的定义相同的过程。
您的程序只想引用一个由libz导出的定义，即函数zlibVersion，在eg2.c中仅引用一次。如果链接器将该引用添加到程序中，然后找到定义由libz导出，引用被解析
但当您尝试链接程序时，如：
gcc -o eg2 -lz eg2.o
事件的顺序是错误的，其方式与示例1相同。在链接器找到-lz时，没有对任何内容的引用在节目中：他们都在eg2.o中，这还没有被看到。所以链接器决定它不适用于libz。当它达到eg2.o时，将其添加到程序中，然后对zlibVersion有未定义的引用，链接序列完成；该引用未解析，链接失败。
最后，示例2的pkg配置变体现在有了一个显而易见的解释。壳体膨胀后：
gcc -o eg2 $(pkg-config --libs zlib) eg2.o
变为：
gcc -o eg2 -lz eg2.o
这再次只是示例2。
我可以重复示例1中的问题，但不能重复示例2中的问题
联动装置：
gcc -o eg2 -lz eg2.o
对你来说很好！
（或者：在Fedora 23上，这种链接很好，但在Ubuntu 16.04上失败了）
这是因为链接工作的发行版是不配置其GCC工具链以根据需要链接共享库。
过去，类unix系统链接静态和共享是很正常的不同的规则。链接序列中的静态库已链接但是共享库是无条件链接的。
这种行为在链接时是经济的，因为链接器不必考虑程序是否需要共享库：如果是共享库，大多数链接中的大多数库都是共享库。但也有缺点：-
这在运行时是不经济的，因为它会导致共享库与程序一起加载，即使不需要它们。静态库和共享库的不同链接规则可能会令人困惑对于不熟练的程序员，他们可能不知道-lfo是否在他们的联系中将解析为/some/where/libfoo.a或/some/wwhere/libfoo.so，并且可能不理解共享库和静态库之间的区别无论如何
这种权衡导致了今天的分裂局面。一些发行版有更改了共享库的GCC链接规则，以便根据需要这一原则适用于所有图书馆。一些发行版沿用了旧版本方法
为什么即使同时编译和链接，我仍然会遇到这个问题？
如果我这样做：
$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
当然，gcc必须首先编译eg1.c，然后链接生成的带有libmy_lib.a的对象文件，那么它怎么可能不知道该对象文件在进行链接时是否需要？
因为使用单个命令编译和链接不会更改连杆顺序。
当您运行上面的命令时，gcc发现您需要编译+链接。因此，在幕后，它生成一个编译命令，并运行然后生成一个链接命令并运行它，就像您运行了两个命令：
$ gcc -I. -c -o eg1.o eg1.c
$ gcc -o eg1 -L. -lmy_lib eg1.o
因此，如果运行这两个命令，链接就会失败。这个您在失败中注意到的唯一区别是gcc生成了编译+链接情况下的临时对象文件，因为您没有告诉它使用eg1.o.我们看到：
/tmp/ccQk1tvs.o: In function `main'
而不是：
eg1.o: In function `main':
另请参见
指定相互依赖的链接库的顺序错误
将相互依赖的库按错误的顺序排列只是一种方法在其中，您可以获取需要对即将到来的事物进行定义的文件在链接中晚于提供定义的文件。将库放在引用它们的对象文件是犯同样错误的另一种方式。
函数或类方法在源文件中使用内联说明符定义。
例如：-
主.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
如果所有其他操作都失败，请重新编译。
最近，我只需重新编译有问题的文件，就可以消除Visual Studio 2012中未解决的外部错误。当我重新构建时，错误消失了。
当两个（或多个）库具有循环依赖关系时，通常会发生这种情况。库A尝试使用B.lib中的符号，库B尝试使用A.lib中的字符。两者都不存在。当您尝试编译A时，链接步骤将失败，因为它找不到B.lib。将生成A.lib，但不会生成dll。然后编译B，这将成功并生成B.lib。重新编译A现在可以工作了，因为现在找到了B.lib。
因为当涉及到链接器错误时，人们似乎都在关注这个问题，所以我将在这里添加这个问题。
GCC 5.2.0中出现链接器错误的一个可能原因是现在默认选择了新的libstdc++库ABI。
如果您在std:：__cxx11命名空间或标记[abi:cx11]中获得了有关符号未定义引用的链接器错误，则可能表明您正在尝试将使用_GLIBCXX_USE_cxx11_abi宏的不同值编译的对象文件链接在一起。这通常发生在链接到使用旧版本GCC编译的第三方库时。如果无法使用新的ABI重建第三方库，则需要使用旧的ABI重新编译代码。
因此，如果在5.1.0之后切换到GCC时突然出现链接器错误，这将是一件值得检查的事情。
推荐文章
- 如何构建和使用谷歌TensorFlow c++ api
- 断言是邪恶的吗?
- 下面这些短语在c++中是什么意思:0 -，default-和value-initialization?
- 在STL地图中，使用map::insert比[]更好吗?
- C++ Linux的想法?
- 如何为Fedora安装g++ ?
- Std::cin输入空格?
- c++标准是否要求iostreams的性能很差，或者我只是在处理一个糟糕的实现?
- gcc在哪里查找C和c++头文件?
- 为什么我们需要require require ?
- 解析c++中的命令行参数?
- 我如何在c++中创建一个随机的字母数字字符串?
- c++中的atan和atan2有什么区别?
- 现代c++能让你免费获得性能吗?
- 一门语言是如何自我扩展的?
