什么是未定义的引用/未解决的外部符号错误，我该如何解决？

如 2.2 (credits to Keith Thompson for the reference) 所指定，编译 C++ 程序需要几个步骤：

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

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

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

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

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

Microsoft Visual Studio 的常见错误消息是 error LNK2001、error LNK1120、error LNK2019 和 GCC 的 undefined reference to 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 定义不一致

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

未为多文件项目配置 Visual Studio Code

班级成员：

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

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

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

发生这种情况是因为当对象被隐式销毁时会调用基类析构函数，因此需要定义。

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

这类似于没有定义的非 virtual 方法，并添加了纯声明生成虚拟 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() {}

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

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

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

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

可以为类定义中的整数或枚举类型的 static const 数据成员提供初始化程序；但是，该成员的 odr 使用仍需要如上所述的命名空间范围定义。 C++11 允许在类内对所有 static const 数据成员进行初始化。

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

通常，每个翻译单元将生成一个目标文件，其中包含在该翻译单元中定义的符号的定义。要使用这些符号，您必须链接到这些目标文件。

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

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

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

这里的 libraryName 只是库的简单名称，没有特定于平台的添加。例如，Linux 库文件通常称为 libfoo.so，但您只需要编写 -lfoo。在 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 将信息放在每个函数底部的一个框中，称为“库”部分。

已声明但未定义变量或函数。

一个典型的变量声明是

extern int x;

由于这只是一个声明，因此需要一个定义。相应的定义是：

int x;

例如，以下将产生错误：

extern int x;
int main()
{
    x = 0;
}
//int x; // uncomment this line for successful definition

类似的评论适用于函数。声明一个函数而不定义它会导致错误：

void foo(); // declaration only
int main()
{
   foo();
}
//void foo() {} //uncomment this line for successful definition

请注意，您实现的函数与您声明的函数完全匹配。例如，您可能有不匹配的 cv 限定符：

void foo(int& x);
int main()
{
   int x;
   foo(x);
}
void foo(const int& x) {} //different function, doesn't provide a definition
                          //for void foo(int& x)
                          

其他不匹配的例子包括

在一个命名空间中声明的函数/变量，在另一个命名空间中定义。

声明为类成员的函数/变量，定义为全局（反之亦然）。

函数返回类型、参数编号和类型以及调用约定并不完全一致。

来自编译器的错误消息通常会为您提供已声明但从未定义的变量或函数的完整声明。将其与您提供的定义进行仔细比较。确保每个细节都匹配。

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

如果库相互依赖，则链接库的顺序很重要。通常，如果库 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

所以再重复一遍，顺序很重要！

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

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

注意：我使用 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;
}

和

// 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

链接器看到导出的符号并链接它。现在我们尝试像这里一样取消注释 src2.cpp 中的行

// 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

至

    .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:
; ...

我们更改了 local_var_name 的可见性并将其值设置为 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 有 Bind GLOBAL (是 LOCAL)

关联

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

并运行它

$ ./prog 
123456789

好的，我们破解它:)

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

符号在 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"
}

如果一切都失败了，请重新编译。

我最近能够通过重新编译有问题的文件来摆脱 Visual Studio 2012 中未解决的外部错误。当我重新构建时，错误消失了。

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

模板实现不可见。

非专业化模板的定义必须对所有使用它们的翻译单元可见。这意味着您不能将模板的定义与实现文件分开。如果您必须分离实现，通常的解决方法是在声明模板的标头末尾包含一个 impl 文件。一个常见的情况是：

template<class T>
struct X
{
    void foo();
};

int main()
{
    X<int> x;
    x.foo();
}

//differentImplementationFile.cpp
template<class T>
void X<T>::foo()
{
}

要解决此问题，您必须将 X::foo 的定义移动到头文件或使用它的翻译单元可见的某个位置。

专门化的模板可以在实现文件中实现，并且实现不必是可见的，但必须事先声明专门化。

有关进一步的解释和另一种可能的解决方案（显式实例化），请参见 this question and answer。

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

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

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

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

编译时生成的所有目标文件

显式或隐式指定为此构建应用程序的附加依赖项的所有库 (.lib)。

这个搜索过程称为resolve。

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

E. LNK2019 的可能原因：未解决的外部符号错误。我们已经知道这个错误是由于链接器未能找到外部符号的定义，可能的原因可以排序为：

定义存在

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

int foo()
{
    return 0;
}

在 b.cpp 中我们要调用函数 foo，所以我们添加

void foo();

声明函数 foo()，并在另一个函数体中调用它，比如 bar()：

void bar()
{
    foo();
}

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

定义不存在

如果我们要调用库中的某些函数，但导入库没有添加到您的项目设置的附加依赖项列表（设置自：Project | Properties | Configuration Properties | Linker | Input | Additional Dependency）中。现在链接器将报告 LNK2019，因为当前搜索范围内不存在该定义。

跨模块/dll（特定于编译器）错误地导入/导出方法/类。

MSVS 要求您使用 __declspec(dllexport) 和 __declspec(dllimport) 指定要导出和导入的符号。

这种双重功能通常是通过使用宏来获得的：

#ifdef THIS_MODULE
#define DLLIMPEXP __declspec(dllexport)
#else
#define DLLIMPEXP __declspec(dllimport)
#endif

宏 THIS_MODULE 只能在导出函数的模块中定义。这样，声明：

DLLIMPEXP void foo();

扩展到

__declspec(dllexport) void foo();

并告诉编译器导出函数，因为当前模块包含它的定义。当在不同的模块中包含声明时，它会扩展为

__declspec(dllimport) void foo();

并告诉编译器该定义在您链接的库之一中（另见 1））。

您可以类似地导入/导出类：

class DLLIMPEXP X
{
};

对 WinMain@16 或类似'unusual' main() 入口点引用的未定义引用（尤其是对于 visual-studio）。

您可能错过了使用实际 IDE 选择正确的项目类型。 IDE 可能希望将例如 Windows 应用程序项目绑定到此类入口点函数（如上面缺少的参考中所指定），而不是常用的 int main(int argc, char** argv); 签名。

如果您的 IDE 支持普通控制台项目，您可能希望选择此项目类型，而不是 Windows 应用程序项目。

以下是从现实世界问题中更详细地处理的 case1 和 case2。

此外，如果您使用的是 3rd 方库，请确保您拥有正确的 32/64 位二进制文件

Microsoft 提供 #pragma 以在链接时引用正确的库；

#pragma comment(lib, "libname.lib")

除了包含库目录的库路径外，这应该是库的全名。

需要为新的工具集版本更新 Visual Studio NuGet 包

我只是在尝试将 libpng 与 Visual Studio 2013 链接时遇到了这个问题。问题是包文件只有 Visual Studio 2010 和 2012 的库。

正确的解决方案是希望开发人员发布一个更新的包然后升级，但它通过入侵 VS2013 的额外设置对我有用，指向 VS2012 库文件。

我通过找到 packagename\build\native\packagename.targets 并在该文件中复制所有 v110 部分来编辑包（在解决方案目录内的 packages 文件夹中）。我在仅条件字段中将 v110 更改为 v120，非常小心地将文件名路径全部保留为 v110。这只是允许 Visual Studio 2013 链接到 2012 年的库，在这种情况下，它起作用了。

假设您有一个用 c++ 编写的大项目，其中包含一千个 .cpp 文件和一千个 .h 文件。假设该项目还依赖于十个静态库。假设我们在 Windows 上，我们在 Visual Studio 20xx 中构建我们的项目。当您按 Ctrl + F7 Visual Studio 开始编译整个解决方案时（假设我们在解决方案中只有一个项目）

编译是什么意思？

Visual Studio 搜索文件 .vcxproj 并开始编译每个扩展名为 .cpp 的文件。编译顺序是未定义的。所以你不能假设文件 main.cpp 是先编译的

如果 .cpp 文件依赖于其他 .h 文件以查找可能在文件 .cpp 中定义或未定义的符号

如果存在一个编译器在其中找不到一个符号的 .cpp 文件，则编译器时错误会引发消息 Symbol x could not be found

为每个扩展名为 .cpp 的文件生成一个目标文件 .o，Visual Studio 还将输出写入名为 ProjectName.Cpp.Clean.txt 的文件中，该文件包含必须由链接器处理的所有目标文件。

编译的第二步由 Linker 完成。Linker 应该合并所有目标文件并最终构建输出（可能是可执行文件或库）

链接项目的步骤

解析所有目标文件并找到仅在标头中声明的定义（例如：前面的答案中提到的类的一种方法的代码，或事件初始化一个类内部成员的静态变量）

如果在目标文件中找不到一个符号，他也会在 Additional Libraries 中进行搜索。为了将新库添加到项目配置属性 -> VC++ 目录 -> 库目录，您在此处指定了用于搜索库和配置属性的附加文件夹 ->链接器 -> 用于指定库名称的输入。 - 如果链接器找不到您在一个 .cpp 中写入的符号，他会引发链接器时间错误，这听起来可能像错误 LNK2001：未解析的外部符号“void __cdecl foo(void)”(?foo@@YAXXZ)

观察

一旦链接器找到一个符号，他就不会在其他库中搜索它 链接库的顺序确实很重要。如果链接器在一个静态库中找到一个外部符号，他会将符号包含在项目的输出中。但是，如果库是共享的（动态），他不会在输出中包含代码（符号），但运行时崩溃可能发生

如何解决此类错误

编译器时间错误：

确保您编写的 c++ 项目语法正确。

链接器时间错误

定义您在头文件中声明的所有符号

使用 #pragma once 允许编译器不包含一个头文件，如果它已经包含在当前编译的 .cpp 中

确保您的外部库不包含可能与您在头文件中定义的其他符号发生冲突的符号

当您使用模板时，请确保在头文件中包含每个模板函数的定义，以允许编译器为任何实例化生成适当的代码。

使用链接器帮助诊断错误

大多数现代链接器都包含一个详细的选项，可以在不同程度上打印出来。

链接调用（命令行），

关于链接阶段包含哪些库的数据，

图书馆的位置，

使用的搜索路径。

对于 gcc 和 clang；您通常会将 -v -Wl,--verbose 或 -v -Wl,-v 添加到命令行。更多详情可在这找到;

Linux ld 手册页。

LLVM 链接器页面。

“GCC 简介”第 9 章。

对于 MSVC，将 /VERBOSE（特别是 /VERBOSE:LIB）添加到链接命令行。

/VERBOSE 链接器选项上的 MSDN 页面。

编译器/IDE 中的错误

我最近遇到了这个问题，结果是 it was a bug in Visual Studio Express 2013。我不得不从项目中删除一个源文件并重新添加它来克服这个错误。

如果您认为这可能是编译器/IDE 中的错误，请尝试以下步骤：

清理项目（某些 IDE 可以选择执行此操作，您也可以通过删除目标文件手动执行此操作）

尝试开始一个新项目，从原始项目中复制所有源代码。

链接的 .lib 文件与 .dll 相关联

我遇到过同样的问题。假设我有项目 MyProject 和 TestProject。我已经有效地将 MyProject 的 lib 文件链接到了 TestProject。但是，这个 lib 文件是在构建 MyProject 的 DLL 时生成的。此外，我没有包含 MyProject 中所有方法的源代码，而只包含对 DLL 入口点的访问。

为了解决这个问题，我将 MyProject 构建为 LIB，并将 TestProject 链接到这个 .lib 文件（我将生成的 .lib 文件复制粘贴到 TestProject 文件夹中）。然后我可以再次将 MyProject 构建为 DLL。它正在编译，因为与 TestProject 链接的库确实包含 MyProject 中类中所有方法的代码。

由于人们似乎在谈到链接器错误时被引导到这个问题，所以我将在此处添加此问题。

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

如果您收到有关对涉及 std::__cxx11 命名空间或标记 [abi:cxx11] 中的类型的符号的未定义引用的链接器错误，则可能表明您正在尝试将使用不同值编译的目标文件链接在一起 _GLIBCXX_USE_CXX11_ABI宏。当链接到使用旧版本 GCC 编译的第三方库时，通常会发生这种情况。如果第三方库不能用新的 ABI 重建，那么你需要用旧的 ABI 重新编译你的代码。

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

您的链接在引用它们的目标文件之前使用库

您正在尝试使用 GCC 工具链编译和链接您的程序。

您的链接指定了所有必要的库和库搜索路径

如果 libfoo 依赖于 libbar，那么您的链接正确地将 libfoo 放在 libbar 之前。

您的链接因未定义对某些错误的引用而失败。

但是所有未定义的东西都在你有#included的头文件中声明，实际上是在你链接的库中定义的。

示例在 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

eg1.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

eg2.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

以及涉及 pkg-config 的示例 2 的变体：

$ 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-config 变体：

$ gcc -o eg2 eg2.o $(pkg-config --libs zlib) 
$ ./eg2
1.2.8

说明

从这里开始，阅读是可选的。

默认情况下，由 GCC 生成的链接命令在您的发行版上按命令行顺序从左到右使用链接中的文件。当它发现一个文件引用了某个东西并且不包含它的定义时，它将在更右边的文件中搜索一个定义。如果它最终找到定义，则解析该引用。如果最后有任何引用仍未解决，则链接失败：链接器不会向后搜索。

首先，示例 1，带有静态库 my_lib.a

静态库是目标文件的索引存档。当链接器在链接序列中找到 -lmy_lib 并确定 this 引用静态库 ./libmy_lib.a 时，它想知道您的程序是否需要 libmy_lib.a 中的任何目标文件。

libmy_lib.a中只有目标文件，即my_lib.o，而my_lib.o中只定义了一个东西，即函数hw。

当且仅当链接器已经知道您的程序在它已添加到程序的一个或多个目标文件中引用 hw 并且没有任何目标文件时，链接器才会决定您的程序需要 my_lib.o它已添加包含 hw 的定义。

如果是这样，那么链接器将从库中提取 my_lib.o 的副本并将其添加到您的程序中。然后，您的程序包含 hw 的定义，因此它对 hw 的引用已解决。

当您尝试像这样链接程序时：

$ gcc -o eg1 -L. -lmy_lib eg1.o

当它看到 -lmy_lib 时，链接器还没有添加 eg1.o 到程序中。因为那时，它还没有看到 eg1.o。您的程序尚未对 hw 进行任何引用：它根本没有进行任何引用，因为它所做的所有引用都在 eg1.o 中。

因此链接器不会将 my_lib.o 添加到程序中，并且对 libmy_lib.a 没有进一步的用途。

接下来，它找到eg1.o，并将其添加到程序中。链接序列中的目标文件总是添加到程序中。现在，程序引用了 hw，并且不包含 hw 的定义；但是链接序列中没有任何东西可以提供缺失的定义。对 hw 的引用最终未解决，并且链接失败。

二、示例 2，使用共享库 libz

共享库不是目标文件或类似文件的存档。它更像是一个程序，它没有 main 函数，而是公开了它定义的多个其他符号，以便其他程序可以在运行时使用它们。

如今，许多 Linux 发行版都配置了他们的 GCC 工具链，以便其语言驱动程序（gcc、g++、gfortran 等）指示系统链接器（ld）在根据需要基础。您拥有其中一个发行版。

gcc -o eg2 -lz eg2.o

gcc -o eg2 $(pkg-config --libs zlib) eg2.o

gcc -o eg2 -lz eg2.o

gcc -o eg2 -lz eg2.o

$ gcc -o eg1 -I. -L. -lmy_lib eg1.c

$ gcc -I. -c -o eg1.o eg1.c
$ gcc -o eg1 -L. -lmy_lib eg1.o

/tmp/ccQk1tvs.o: In function `main'

eg1.o: In function `main':