编译器/IDE中的错误

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

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

清理项目（一些IDE可以选择这样做，您也可以手动删除对象文件）尝试启动新项目，从原始代码复制所有源代码。

编译C++程序分几个步骤进行，如2.2所述（Keith Thompson作为参考）：

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

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

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

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

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

常见的错误消息包括错误LNK2001、错误LNK1120、错误LNK2019（适用于Microsoft Visual Studio）和未定义的对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

常见原因包括：

未能链接到适当的库/对象文件或编译实现文件已声明和未定义的变量或函数。类类型成员的常见问题模板实现不可见。符号是在C程序中定义的，并在C++代码中使用。跨模块.dll错误地导入/导出方法/类。（特定于MSVS）循环库依赖关系对的未定义引用`WinMain@16'相互依赖的库顺序多个同名源文件使用#pragma（Microsoft Visual Studio）时键入错误或不包含.lib扩展名模板好友问题UNICODE定义不一致常量变量声明/定义中缺少“extern”（仅限C++）未为多文件项目配置Visual Studio代码在Mac OS X上构建dylib时出错，但在其他Unix-y系统上也可以

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

MSVS要求您使用__declspec（dllexport）和__declsspec（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
{
};

符号是在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和clang；通常会在命令行中添加-v-Wl、--verbose或-v-Wl和-v。更多详情请点击此处；

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

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

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

尽管这是一个有多个公认答案的老问题，但我想分享如何解决一个晦涩的“未定义引用”错误。

不同版本的库

我使用别名来引用std:：filesystem：：path：filesystem自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的＜实验：：filesystem＞，并包含上面的代码file.cpp，file.h的实现，#include的“file.h”main.cpp#include的<文件系统>和“file.h”

注意main.cpp和file.h中使用的不同库。由于main.cpp#在＜filesystem＞之后包含了“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-lsdc++fs->链接main.o和file.o

这样，任何包含在file.o中并在main.o中使用的需要path_t的函数都会出现“未定义的引用”错误，因为main.o引用std:：filesystem：：path，而file.o引用的是std:：experimental：：filesystem:：path。

决议

为了解决这个问题，我只需要将file.h中的＜experimental：：filesystem＞更改为＜filesystem＞。