什么是未定义的引用/未解析的外部符号错误以及如何修复它？

Question

什么是未定义的引用/未解析的外部符号错误？常见原因有哪些？如何修复和预防这些错误？

Answer 1

说您有以下代码：

// a.cpp
int get() { return 0; }

// b.cpp
int get(); // usually, one doesn't write this directly, but gets these
           // declarations from included header files
int x = get();

编译 b.cpp 时，编译器只是假设 get（）符号被定义为 虽然在乎哪里。链接阶段负责查找符号并正确链接从 a.cpp 和 b.cpp 的对象文件。

如果 A.CPP 未定义 get ，则会获得一个链接器错误，说“未定义的参考”或“未解决的外部符号”。

C ++标准措辞

编译A C ++程序在，其中的最后一个相关：

9。所有外部实体参考均已解决。
库组件链接到满足当前翻译中未定义的实体的外部引用。
将所有此类翻译器输出收集到程序映像中，其中包含在其执行环境中执行所需的信息。

请参阅基思·汤普森（Keith Thompson）的答案有关这些阶段的摘要。

指定的错误发生在汇编的最后阶段，最常见地称为链接。这基本上意味着您将一堆源文件编译到对象文件或库中，现在您想让它们一起工作。

实践中的链接器错误

如果您使用的是Microsoft Visual Studio，则会看到项目生成 .lib 文件。这些包含一个导出的符号表和进口符号表。导入的符号针对您链接的库解决，并为使用该 .lib （如果有）的库提供导出的符号。

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

常见错误消息是错误LNK2001 ，错误lnk1120 ，错误lnk2019 for Microsoft Visual Studio and 未定义的参考 符号名称 gcc 。

代码：

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

常见原因

• 未能针对适当的库/对象文件链接或编译实现文件
• 已声明且未定义的可变或函数。
• < a href =“ https://stackoverflow.com/a/125744407”> class-type成员常见
• 问题。
• 在C程序中定义了符号，并在C ++代码中使用。
• 跨模块/dll的错误导入/导出方法/类。 （特定于MSVS）
• 圆形库依赖性
• n winmain@16'
• 同名的多个源文件
• =“ https://stackoverflow.com/a/25744263”>误解或不包括.lib扩展时，使用 #pragma （Microsoft Visual Studio）
• ：//stackoverflow.com/a/35891188“>模板朋友的问题
• 不一致 unicode unicode 定义
• const变量声明/定义（仅C ++）中缺少“ extern”
• /a/72328407“> Visual Studio代码未为多个文件项目配置
• ​
• ​href =“ https://stackoverflow.com/a/78305548”>您的链接包含C ++对象文件和C ++库，源自不同的C ++编译器

Answer 2

类成员：

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

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

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

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

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

这与没有定义的非虚拟方法类似，但增加了以下推理：
pure 声明会生成一个虚拟 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() 声明为 pure：

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

Non-virtual 类成员

即使未显式使用，某些成员也需要定义：

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

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

Answer 3

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

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

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

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

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

这里的libraryName只是库的简单名称，没有特定于平台的添加。例如，在 Linux 上，库文件通常称为 libfoo.so，但您只需编写 -lfoo。在 Windows 上，同一文件可能称为 foo.lib，但您将使用相同的参数。您可能必须使用 -L 添加可以找到这些文件的目录。确保 -l 或 -L 后不要写入空格。

对于 Xcode：添加用户标头搜索路径 ->添加库搜索路径->将实际的库引用拖放到项目文件夹中。

在MSVS下，添加到项目中的文件会自动将其目标文件链接在一起，并会生成lib文件（常用）。要在单独的项目中使用这些符号，您需要
需要在项目设置中包含 lib 文件。这是在项目属性的“链接器”部分的“输入 ->”中完成的。附加依赖项。 （lib 文件的路径应该是
添加到 Linker ->一般->其他库目录）当使用随 lib 文件提供的第三方库时，不这样做通常会导致错误。

您也可能忘记将文件添加到编译中，在这种情况下将不会生成目标文件。在gcc中，您可以将文件添加到命令行。在 MSVS 中，将文件添加到项目中将使其自动编译（尽管可以手动将文件单独从构建中排除）。

在 Windows 编程中，未链接必要库的标志是未解析符号的名称以 __imp_ 开头。在文档中查找函数的名称，它应该说明您需要使用哪个库。例如，MSDN 将信息放在每个函数底部名为“库”的部分中的框中。

Answer 4

声明但未定义变量或功能。

典型的变量声明是

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 Qualifier：

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)
                          

其他不匹配示例包括

• 在一个名称空间中声明的功能/变量，在另一个命名空间中声明。
• 函数/变量称为类成员，定义为全局（反之亦然）。
• 函数返回类型，参数编号和类型以及调用约定并不完全同意。

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

Answer 5

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

如果库相互依赖，则库链接的顺序很重要。一般来说，如果库A依赖于库B，那么libA必须出现在libB之前code> 在链接器标志中。

例如：

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

所以再次重复一下，顺序确实很重要！

Answer 6

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

void foo（）在C程序中定义了

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

函数（或变量） AS：

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

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

extern "C" void foo();

您尝试使用它在C ++程序中使用它C ++链接。

如果整个库都包含在标题文件中（并将其编译为C代码）；包括的包含如下；

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

Answer 7

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

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

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

Make 目标文件。

$ 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

OK（没有错误），因为我们只构建目标文件，链接尚未完成。
尝试链接

$ 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

ie，您应该如下所示

    .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 已绑定 GLOBAL （是 LOCAL）

链接

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

并运行它

$ ./prog 
123456789

，我们破解它:)

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

Answer 8

如果所有其他方法都失败了，请重新编译。

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

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

Answer 9

模板实现不可见。

非专用模板的定义必须对所有使用它们的翻译单元可见。这意味着你不能分离模板的定义
到实施文件。如果必须分离实现，通常的解决方法是使用一个 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 的定义移至头文件或使用它的翻译单元可见的某个位置。

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

有关进一步的说明和另一种可能的解决方案（显式实例化），请参阅此问题和解答。

Answer 10

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

a。什么是符号？
简而言之，符号是一个名称。它可以是一个变量名称，函数名称，类名称，typedef名称或除了属于C ++语言的那些名称和标志之外的任何内容。它是由依赖项库（另一个用户定义）定义或介绍的用户。

b。什么是外部？
在VC ++中，每个源文件（.cpp，.c等）被视为翻​​译单元，编译器一次编译一个单元，并为当前翻译单元生成一个对象文件（.OBJ）。 （请注意，包含此源文件的每个标头文件都将进行预处理，并将被视为该翻译单元的一部分）翻译单元中的所有内容都被视为内部，其他所有内容都被视为外部。在C ++中，您可以使用 extern ， __ extspec（dllimport）等关键字来引用外部符号。

c。什么是“解决”？
解析是一个链接时间。在链接时间时，链接器试图找到对象文件中无法在内部找到其定义的每个符号的外部定义。此搜索过程的范围包括：

• 在编译时间中生成的所有对象文件，
• 所有库（.lib）是明确或隐式的
  指定为该建筑物应用程序的其他依赖关系。

此搜索过程称为Resolve。

d。最后，为什么未解决的外部符号？
如果链接器无法找到没有内部定义的符号的外部定义，则报告未解决的外部符号错误。

e。 LNK2019的可能原因：未解决的外部符号错误。
我们已经知道，此错误是由于链接器未能找到外部符号的定义，因此可能的原因可以按以下方式排序：

1. 将其排序。

例如，如果我们具有在A.CPP中定义的称为FOO的函数，则

int foo()
{
    return 0;
}

可以 我们要调用function foo，因此我们添加

void foo();

到声明函数foo（），然后在另一个功能主体中调用它，例如 bar（）：

void bar()
{
    foo();
}

现在，当您构建此代码时，您将获得LNK2019错误该Foo是未解决的符号。在这种情况下，我们知道FOO（）在A.CPP中具有其定义，但与我们所调用的定义不同（不同的返回值）。存在定义的情况。

2. 则不存在定义

如果我们要在库中调用某些函数， ，但是未将导入库添加到附加依赖项列表中（设置为： project | properties |配置属性|链接|链接|输入|附加依赖关系）您的项目设置。现在，链接器将报告LNK2019，因为该定义在当前搜索范围中不存在。

Answer 11

跨模块/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
{
};

Answer 12

对 WinMain@16 的未定义引用或类似的'unusual' main() 入口点引用（特别是对于 视觉工作室）。

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

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

---

以下是案例1 和案例2从现实世界问题中更详细地处理。

Answer 13

另外，如果您正在使用第三方库，请确保您拥有正确的32/64位二进制文​​件

Answer 14

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

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

除了库路径（包括库的目录）外，这还应该是库的全名。

Answer 15

Visual Studio Nuget软件包需要更新新的Toolset版本

我只是遇到了这个问题，试图将libpng与Visual Studio 2013链接起来。问题是该软件包文件仅具有Visual Studio 2010和2012的库。

正确的解决方案是希望开发人员发布更新的软件包，然后升级，但它可以通过在VS2013的额外设置中进行黑客攻击，指向VS2012库文件。

I edited the package (in the packages folder inside the solution's directory) by finding packagename\build\native\packagename.targets and inside that file, copying all the V110 部分。我将 v110 更改为 v120 in 条件字段仅非常小心地将文件名路径全部留为 v110 。这只是允许Visual Studio 2013链接到2012年的图书馆，在这种情况下，它起作用了。

Answer 16

假设您有一个用 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发现
• 对于每个扩展名为 .cpp 的文件，都会生成一个目标文件 .o，并且 Visual Studio 将输出写入名为 ProjectName.Cpp.Clean.txt 的文件中，该文件包含以下所有目标文件：必须处理由链接器。

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

链接项目的步骤

• 解析所有目标文件并找到仅在标头中声明的定义（例如：前面的答案中提到的类的一种方法的代码，或者作为类内部成员的静态变量的初始化）
• 如果在中找不到一个符号他还在附加中搜索目标文件库。用于将新库添加到项目配置属性 -> VC++ 目录 -> 库目录，您在此处指定了用于搜索库和配置属性的附加文件夹 -> 链接器 -> 输入用于指定库的名称。
  -如果链接器找不到您在一个 .cpp 中编写的符号，他会引发一个链接器时间错误，听起来可能像
  错误 LNK2001：无法解析的外部符号“void __cdecl foo(void)”(?foo@@YAXXZ)

观察

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

如何解决此类错误

编译器时间错误：

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

链接器时间错误

• 定义您在头文件中声明的所有符号
• 使用 #pragma Once 允许编译器不包含一个头文件（如果该头文件已包含在已编译的当前 .cpp 中）
• 请确保您的外部库不包含可能与您在头文件中定义的其他符号发生冲突的符号
• 当您使用模板时，请确保在头文件中包含每个模板函数的定义，以允许编译器生成适当的代码任何实例化。

Answer 17

使用链接器帮助诊断错误

大多数现代链接器都包含一个可以不同程度打印的详细选项；

• 链接调用（命令行）、
• 链接阶段包含哪些库的数据、
• 库的位置、
• 使用的搜索路径。

对于 gcc 和 clang；您通常会在命令行中添加 -v -Wl,--verbose 或 -v -Wl,-v 。更多详细信息可以在这里找到；

• Linux ld 手册页。
• LLVM 链接器页面。
• “GCC 简介”第 9 章。

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

• /VERBOSE 链接器选项。

Answer 18

编译器/IDE 中的错误

我最近遇到了这个问题，结果这是 Visual Studio Express 2013 中的一个错误。我必须从项目中删除源文件并重新添加它以克服该错误。

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

• 清理项目（某些 IDE 可以选择执行此操作，您也可以
  通过删除目标文件手动完成）
• 尝试启动一个新项目，
  从原始源代码复制所有源代码。

Answer 19

链接.lib文件与.dll

我遇到了同样的问题。说我有项目myproject和testproject。我有效地将LIB文件链接到了testProject。但是，该LIB文件是作为构建Myproject的DLL生成的。另外，我不包含MyProject中所有方法的源代码，而仅包含对DLL的输入点的访问。

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

Answer 20

由于人们在链接错误错误时似乎是针对这个问题的，所以我将在此处添加此问题。

使用GCC 5.2.0的链接器错误的一个可能原因是，默认情况下，选择了一个新的libstdc ++库ABI。

如果您获得了有关不确定的引用到涉及std :: __ cxx11命名空间或标签[abi：cxx11]的符号的链接错误，则可能表明您试图将链接到与不同值的对象文件中链接在一起对于_glibcxx_use_cxx11_abi宏。当链接到使用较旧版本的GCC编辑的第三方库时，通常会发生这种情况。如果第三方库无法与新的ABI进行重建，则您需要将代码与旧的ABI重新编译。

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

Answer 21

您的链接在引用库的目标文件之前消耗库

• 您正在尝试使用 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

一个涉及 a 的最小示例共享系统库、压缩库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。

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

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

当您尝试链接程序时，例如：

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

链接器在看到时尚未添加 eg1.o 到程序
-lmy_lib。因为此时它还没有看到 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) 根据需要链接共享库。
您已经获得了这些发行版之一。

这意味着当链接器在链接序列中找到 -lz 并发现 this 引用时
到共享库（例如）/usr/lib/x86_64-linux-gnu/libz.so，它想知道它添加到程序中但尚未定义的任何引用是否具有由 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-config 变体现在有了显而易见的解释。
shell 扩展后：

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 系统链接静态和共享是很正常的
图书馆按不同的规则。链接序列中的静态库被链接
在示例 1 中解释的按需基础上，但共享库是无条件链接的。

这种行为在链接时很经济，因为链接器不必考虑
程序是否需要共享库：如果是共享库，
链接它。大多数链接中的大多数库都是共享库。但也有缺点：-

• 在运行时是不经济的，因为它可能导致共享库
  与程序一起加载，即使不需要它们。

• 静态库和共享库的不同链接规则可能会令人困惑
  对于不熟练的程序员，他们可能不知道 -lfoo 是否在其链接中
  将解析为 /some/where/libfoo.a 或 /some/where/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':

另请参阅

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

将相互依赖的库按错误的顺序放置只是一种方式
您可以在其中获取需要即将到来的事物的定义的文件
链接中比提供定义的文件晚。将库放在前面
引用它们的目标文件是犯同样错误的另一种方式。

Answer 22

围绕GNU LD的包装器不支持Linker脚本

某些.So文件实际上是 gnu ld链接脚本，eg

INPUT (libtbb.so.2)

一些更复杂的构建可能不支持这一点。例如，如果您在编译器选项中包含-v，则可以看到 mainwin gcc Wrapper mwdip 在要链接的库库列表中丢弃链接器脚本命令文件。围绕的简单工作是用文件的副本（或symlink）替换链接器脚本输入命令文件，例如

cp libtbb.so.2 libtbb.so

，例如将-l参数替换为.so的完整路径，例如 -ltbb do /home/foo/tbb-4.3/linux/lib/lib/intel64/gcc4.4/libtbb .so.2

Answer 23

与模板交友...

给定带有友元运算符（或函数）的模板类型的代码片段；

template <typename T>
class Foo {
    friend std::ostream& operator<< (std::ostream& os, const Foo<T>& a);
};

运算符<<被声明为非模板函数。对于与 Foo 一起使用的每种类型 T，都需要有一个非模板化运算符<<。例如，如果声明了类型 Foo，则必须有一个运算符实现，如下所示；

std::ostream& operator<< (std::ostream& os, const Foo<int>& a) {/*...*/}

由于它没有实现，链接器无法找到它并导致错误。

要纠正此问题，您可以在 Foo 类型之前声明一个模板运算符，然后将适当的实例化声明为友元。语法有点尴尬，但看起来如下；

// forward declare the Foo
template <typename>
class Foo;

// forward declare the operator <<
template <typename T>
std::ostream& operator<<(std::ostream&, const Foo<T>&);

template <typename T>
class Foo {
    friend std::ostream& operator<< <>(std::ostream& os, const Foo<T>& a);
    // note the required <>        ^^^^
    // ...
};

template <typename T>
std::ostream& operator<<(std::ostream&, const Foo<T>&)
{
  // ... implement the operator
}

上面的代码将操作符的友谊限制为Foo的相应实例化，即operator<< 实例化仅限于访问 Foo 实例化的私有成员。

替代方案包括：

• 允许友谊扩展到模板的所有实例，如下所示；

  模板 <类型名称 T>
  类 Foo {
      模板 <类型名称 T1>
      朋友 std::ostream&运算符 <<(std::ostream& os, const Foo& a);
      // ...
  };
  

• 或者，运算符<<的实现可以在类定义中内联完成；

  模板 <类型名称 T>
  类 Foo {
      朋友 std::ostream&运算符<<（std::ostream&os，const Foo&a）
      { /*...*/ }
      // ...
  };
  

注意，当运算符（或函数）的声明仅出现在类中时，该名称不可用于“正常”查找，只能用于参数相关查找，来自 cppreference;

首先在类或类模板 X 中的友元声明中声明的名称将成为 X 的最内层封闭命名空间的成员，但无法进行查找（考虑 X 的参数相关查找除外），除非在提供了命名空间范围...

有关模板好友的进一步阅读，请访问 cppreference 和<一href="https://isocpp.org/wiki/faq/templates#template-friends" rel="noreferrer">C++ 常见问题解答。

显示上述技术的代码列表。

---

作为失败代码示例的旁注； g++ 对此发出如下警告

警告：友元声明 'std::ostream&运算符<<(...)'声明一个非模板函数[-Wnon-template-friend]

注意：（如果这不是您想要的，请确保函数模板已经声明，并在此处的函数名称后面添加 <> ）

Answer 24

当您的包含路径是不同的

链接器错误时，当标头文件及其关联的共享库（.lib文件）消失时，可能会发生错误。让我解释一下。

链接器如何工作？通过比较其签名，链接器将函数声明（在标题中声明）与其定义（在共享库中）匹配。如果链接器找不到完美匹配的函数定义，则可以获得链接器错误。

即使声明和定义似乎匹配，是否仍然可能会出现链接器错误？是的！它们在源代码中可能看起来相同，但这实际上取决于编译器所看到的。从本质上讲，您可以最终以这样的情况：

// header1.h
typedef int Number;
void foo(Number);

// header2.h
typedef float Number;
void foo(Number); // this only looks the same lexically

请注意，即使两个函数声明在源代码中看起来相同，但是根据编译器，它们确实有所不同。

您可能会问一个这样的情况如何结束？ 当然包括路径！如果在编译共享库时，Inclubel路径会导致 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(...);
}

繁荣！您会收到链接器错误，并且不知道为什么会失败。原因是通用库使用相同的不同版本包括 common_math.h （我在示例中通过包括不同的路径而在此使其显而易见，但并不总是那么明显。也许也许。编译器设置中的包含路径不同。

请注意，在此示例中，链接器会告诉您它找不到 draw（），而实际上您知道它显然是由库导出的。您可能会花几个小时挠头想知道出了什么问题。问题是，链接器看到了不同的签名，因为参数类型略有不同。在示例中，就编译器而言， vec3 在两个项目中都是不同的类型。这可能发生，因为它们来自两个稍有不同的文件（也许包含文件来自库的两个不同版本）。

请调试Linker

如果您正在使用Visual Studio， Dumpbin是您的朋友。我敢肯定，其他编译器还有其他类似的工具。

该过程像这样：

1. 请注意链接器错误中给出的怪异的杂乱无章的名称。 （例如draw@graphics@xyz）。
2. 将导出的符号从库将导出的符号转移到文本文件中。
3. 搜索出口的感兴趣符号，并注意弄糊名的名称不同。
4. 请注意为什么操纵名称最终会有所不同。您将能够看到参数类型是不同的，即使它们在源代码中看起来相同。
5. 原因不同的原因。在上面给出的示例中，由于包括不同的文件，它们是不同的。

[1]通过项目，是指一组源文件，这些文件链接在一起以生成库或可执行文件。

编辑1：重写第一部分以易于理解。请在下面发表评论，让我知道是否需要修复其他问题。谢谢！

Answer 25

不一致的 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 等。这是一个明显的迹象，该代码最初旨在用于 UNICODE 和多字节字符（或“窄”）构建。

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

1. 这可以用任何一个来完成；

   <前><代码>#define UNICODE
   #定义_UNICODE

2. 或者在项目设置中；

   <块引用>

   项目属性>一般>项目默认值>字符集

3. 或在命令行上；

   <前><代码>/DUNICODE /D_UNICODE

如果不打算使用 UNICODE，则另一种方法也适用，请确保未设置定义，和/或在项目中使用多字符设置并一致应用。

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

Answer 26

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

对于来自 C 的人来说，C++ 中的全局 const 变量具有内部（或静态）可能会令人惊讶连锁。在 C 中，情况并非如此，因为所有全局变量都隐式地 extern （即当 static 关键字缺失时）。

示例：

// file1.cpp
const int test = 5;    // in C++ same as "static const int test = 5"
int test2 = 5;

// file2.cpp
extern const int test;
extern int test2;

void foo()
{
 int x = test;   // linker error in C++ , no error in C
 int y = test2;  // no problem
}

正确的做法是使用头文件并将其包含在 file2.cpp 和 file1.cpp 中

extern const int test;
extern int test2;

或者，可以在 file1.cpp 中使用显式 const 变量>外部

Answer 27

清理和重建

构建的“清理”可以消除以前的构建、失败的构建、不完整的构建和其他构建系统相关的构建问题中可能留下的“死木”。

一般来说，IDE 或构建将包括某种形式的“干净”功能，但这可能未正确配置（例如在手动 makefile 中）或可能失败（例如中间或生成的二进制文件是只读的）。

一旦“clean”完成，请验证“clean”是否已成功并且所有生成的中间文件（例如自动生成文件）是否已成功删除。

这个过程可以被视为最后的手段，但通常是一个好的第一步；特别是如果最近添加了与错误相关的代码（在本地或从源存储库）。

Answer 28

尽管这是一个相当老的问题，有多个可接受的答案，但我想分享如何解决模糊“未定义的引用”错误。

不同版本的库

我使用别名来引用 std::filesystem::path：文件系统自 C++17 起就位于标准库中，但我的程序也需要在 C 中编译++14 所以我决定使用变量别名：

#if (defined _GLIBCXX_EXPERIMENTAL_FILESYSTEM) //is the included filesystem library experimental? (C++14 and newer: <experimental/filesystem>)
using path_t = std::experimental::filesystem::path;
#elif (defined _GLIBCXX_FILESYSTEM) //not experimental (C++17 and newer: <filesystem>)
using path_t = std::filesystem::path;
#endif

假设我有三个文件：main.cpp、file.h、file.cpp：

• file.h #include's <实验::文件系统>并包含上面的代码
• file.cpp，file.h的实现，#include的“file.h”
• ma​​in.cpp #include的< ;文件系统>和“file.h”

请注意 main.cpp 和 file.h 中使用的不同的库。由于 main.cpp 在 <filesystem> 之后 #include'd“file.h”，因此使用的文件系统版本是 C++17 版本。我曾经使用以下命令编译程序：

$ g++ -g -std=c++17 -c main.cpp ->将 main.cpp 编译为 main.o
$ g++ -g -std=c++17 -c file.cpp ->将file.cpp和file.h编译为file.o
$ g++ -g -std=c++17 -o 可执行文件 main.o file.o -lstdc++fs ->链接 main.o 和 file.o

这样任何函数包含在 file.o 中并在 main.o 中使用，必需的 path_t 给出“未定义”引用”错误，因为 ma​​in.o 引用了 std::filesystem::path 但 file.o 引用了 std::filesystem::path std::experimental::filesystem::path。

解决方案

要解决此问题，我只需要更改 ;在 file.h 中到 。

Answer 29

链接共享库时，请确保所使用的符号未被隐藏。

gcc 的默认行为是所有符号都是可见的。但是，当使用选项 -fvisibility=hidden 构建翻译单元时，只有标有 __attribute__ ((visibility ("default"))) 的函数/符号是外部的结果共享对象。

您可以通过调用来检查您正在查找的符号是否是外部的：

# -D shows (global) dynamic symbols that can be used from the outside of XXX.so
nm -D XXX.so | grep MY_SYMBOL 

隐藏/本地符号以小写符号类型的 nm 显示，例如 t 而不是 `T对于代码段：

nm XXX.so
00000000000005a7 t HIDDEN_SYMBOL
00000000000005f8 T VISIBLE_SYMBOL

您还可以使用 nm 和选项 -C 来对名称进行解析（如果使用了 C++）。

与 Windows-dll 类似，可以用定义来标记公共函数，例如 DLL_PUBLIC 定义为：

#define DLL_PUBLIC __attribute__ ((visibility ("default")))

DLL_PUBLIC int my_public_function(){
  ...
}

大致对应于 Windows'/MSVC-version：

#ifdef BUILDING_DLL
    #define DLL_PUBLIC __declspec(dllexport) 
#else
    #define DLL_PUBLIC __declspec(dllimport) 
#endif

更多 有关可见性的信息可以在 gcc wiki 上找到。

---

当使用 -fvisibility=hidden 编译翻译单元时，生成的符号仍然具有外部链接（按 nm 以大写符号类型显示），并且可以用于外部链接，而无需如果目标文件成为静态库的一部分，就会出现问题。仅当目标文件链接到共享库时，链接才变为本地链接。

要查找目标文件中的哪些符号被隐藏，请运行：

>>> objdump -t XXXX.o | grep hidden
0000000000000000 g     F .text  000000000000000b .hidden HIDDEN_SYMBOL1
000000000000000b g     F .text  000000000000000b .hidden HIDDEN_SYMBOL2

Answer 30

当我们在程序中有对对象名称（类，函数，变量等）的引用时，就会发生“ 未定义的参考”错误，并且链接器在尝试在此中搜索它时找不到其定义。所有链接的对象文件和库。

因此，当链接器找不到链接对象的定义时，它会发出“未定义的参考”错误。从定义来看，此错误发生在链接过程的后期阶段。有多种原因导致“未定义的参考”错误。

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

＃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 ++ ID中指定错误的项目类型并尝试做项目不期望的事情时，我们会获得“未定义的参考”。

＃5）没有库

如果程序员未正确指定图书馆路径或完全忘记了指定它，那么我们将获得程序从库中使用的所有参考文献。

＃6）未编译依赖性文件

程序员必须确保我们事先编译项目的所有依赖项，以便当我们编译项目时，编译器会找到所有依赖项并成功地编译。如果任何依赖项都缺少，则编译器给出“未定义的参考”。

除了上面讨论的原因外，在许多其他情况下可能会出现“未定义的参考”错误。但最重要的是，程序员弄错了问题，为了防止此错误，应纠正它们。