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

Question

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

Answer 1

当我们在程序中引用对象名称（类、函数、变量等）并且链接器尝试在以下位置搜索它时找不到其定义时，就会出现“未定义引用”错误所有链接的目标文件和库。

因此，当链接器找不到链接对象的定义时，它会发出“未定义的引用”错误。从定义中可以清楚地看出，此错误发生在链接过程的后期阶段。导致“未定义引用”错误的原因有多种。

一些可能的原因（更常见）：

#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()”函数。当我们单独编译这些文件时，第一个文件为 print 函数提供了“未定义的引用”，而第二个文件为 main 函数提供了“未定义的引用”。

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) 依赖文件未编译

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

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

Answer 2

假设您有以下代码：

// 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++ 标准措辞

编译 C++ 程序分为 [lex.phases]，最后一个是相关的：

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

有关这些阶段的摘要，请参阅 Keith Thompson 的回答。

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

实践中的链接器错误

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

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

常见的错误消息有 Microsoft Visual Studio 的错误 LNK2001、错误 LNK1120、错误 LNK2019 和 未定义的引用为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

常见原因

• 无法链接到适当的库/对象文件或编译实现文件
• 声明和未定义的变量或函数。
• <一个href="https://stackoverflow.com/a/12574407">类类型成员的常见问题
• 模板实现不可见。
• 符号在 C 程序中定义并在 C++ 代码中使用。
• 跨模块/dll 错误地导入/导出方法/类。 （特定于 MSVS）
• 循环库依赖
• 对“WinMain@16”的未定义引用
• 相互依赖的库顺序
• 多个同名源文件
• 输入错误或不包含使用 #pragma (Microsoft Visual Studio) 时的 .lib 扩展名
• 模板好友的问题
• 不一致的 UNICODE 定义
• const 变量声明/定义中缺少“extern”（仅限 C++）
• 未针对多文件项目配置 Visual Studio Code
• 在 Mac OS X 上构建项目时出现错误dylib，但其他 Unix-y 系统上的 .so 是可以的
• 您的链接在引用库的对象文件之前消耗库
• 您的链接包含源自不同 C++ 编译器的 C++ 对象文件和 C++ 库

Answer 3

类成员：

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

声明析构函数为 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 4

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

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

在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 5

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

典型的变量声明是

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)
                          

其他不匹配的示例包括

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

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

Answer 6

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

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

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

Answer 8

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

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

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

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

最近，我只需重新编译有问题的文件即可消除 Visual Studio 2012 中未解决的外部错误。当我重新构建时，错误消失了。

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

Answer 10

模板实现不可见。

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

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

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

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

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

• 编译时生成的所有目标文件
• 所有显式或隐式的库 (.lib)
  指定为该构建应用程序的附加依赖项。

这个搜索过程称为解析。

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

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

1. 定义存在

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

int foo()
{
    return 0;
}

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

void foo();

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

void bar()
{
    foo();
}

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

2. 定义不存在

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

Answer 12

跨模块/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 13

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

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

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

---

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

Answer 14

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

Answer 15

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

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

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

Answer 16

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

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

正确的解决方案是希望开发人员发布更新的包，然后升级，但它对我来说是通过在 VS2013 中进行额外设置，指向 VS2012 库文件来实现的。

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

Answer 17

假设您有一个用 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 18

使用链接器帮助诊断错误

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

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

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

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

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

• /VERBOSE 链接器选项。

Answer 19

编译器/IDE 中的错误

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

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

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

Answer 20

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

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

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

Answer 21

由于人们在涉及链接器错误时似乎会被引导到这个问题，因此我将在此处添加此内容。

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

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

因此，如果您在 5.1.0 之后切换到 GCC 时突然出现链接器错误，则需要检查一下。

Answer 22

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

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

不支持链接描述文件的 GNU ld 包装器

一些 .so 文件实际上是 GNU ld 链接器脚本，例如 libtbb.so 文件是一个包含以下内容的 ASCII 文本文件：

INPUT (libtbb.so.2)

一些更复杂的版本可能不支持此功能。例如，如果在编译器选项中包含 -v，则可以看到 mainwin gcc 包装器 mwdip 丢弃要链接的库的详细输出列表中的链接器脚本命令文件。一个简单的解决方法是将链接器脚本输入命令文件替换为文件的副本（或符号链接），例如

cp libtbb.so.2 libtbb.so

或者您可以替换 -l 参数使用 .so 的完整路径，例如，代替 -ltbb 执行 /home/foo/tbb-4.3/linux/lib/intel64/gcc4.4/libtbb.so.2< /代码>

Answer 24

与模板交友...

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

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 25

当包含路径不同时，

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

链接器如何工作？链接器通过比较函数声明（在标头中声明）与其定义（在共享库中）来匹配它们的签名。如果链接器找不到完美匹配的函数定义，您可能会收到链接器错误。

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

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

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

请注意，尽管两个函数声明在源代码中看起来相同，但根据编译器的不同，它们实际上是不同的。

你可能会问，一个人怎么会陷入这样的境地呢？ 当然包括路径！如果在编译共享库时，包含路径指向 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(...);
}

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

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

如果您使用的是 Visual Studio，那么调试链接器

DUMPBIN 是您的好朋友。我确信其他编译器也有其他类似的工具。

这个过程是这样的：

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

[1] 我所说的项目是指链接在一起以生成库或可执行文件的一组源文件。

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

Answer 26

不一致的 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 27

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 28

清理和重建

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

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

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

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

Answer 29

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

不同版本的库

我使用别名来引用 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 #include'd "file.h" 在 <filesystem> 之后，使用的文件系统版本是 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 30

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

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