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

对于来自C语言的人来说，在C++中，全局常量变量具有内部（或静态）联系可能是一件令人惊讶的事情。在C中情况并非如此，因为所有全局变量都是隐式外部变量（即，当缺少静态关键字时）。

例子：

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

或者，可以使用显式extern在file1.cpp中声明const变量

班级成员：

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

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

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

这是因为在隐式销毁对象时调用基类析构函数，因此需要定义。

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

这类似于没有定义的非虚拟方法，增加了如下推理：纯声明会生成一个虚拟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() {}

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

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

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

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

可以为类定义中的整型或枚举类型的静态常量数据成员提供初始值设定项；然而，odr使用这个成员仍然需要如上所述的命名空间范围定义。C++11允许在类内初始化所有静态常量数据成员。

使用链接器帮助诊断错误

大多数现代链接器都有一个冗长的选项，可以在不同程度上打印出来；

链接调用（命令行），关于链接阶段中包括哪些库的数据，库的位置，使用的搜索路径。

用于gcc和clang；通常会在命令行中添加-v-Wl、--verbose或-v-Wl和-v。更多详情请点击此处；

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

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

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

不同的架构

您可能会看到这样的消息：

library machine type 'x64' conflicts with target machine type 'X86'

在这种情况下，这意味着可用符号用于不同于您正在编译的体系结构。

在Visual Studio上，这是由于错误的“平台”，您需要选择正确的平台或安装正确版本的库。

在Linux上，这可能是由于错误的库文件夹（例如，使用lib而不是lib64）。

在MacOS上，可以选择在同一文件中传送两种体系结构。可能是链接希望两个版本都存在，但只有一个版本存在。也可能是库所在的lib/lib64文件夹错误。

当您使用错误的编译器构建程序时

如果您使用的是gcc或clang编译器套件，则应根据所使用的语言使用正确的编译器驱动程序。使用g++或clang++编译和链接C++程序。改用gcc或clang将导致对C++标准库符号的引用未定义。例子：

$ gcc -o test test.cpp    
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccPv7MvI.o: warning: relocation against `_ZSt4cout' in read-only section `.text' 
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccPv7MvI.o: in function `main': test.cpp:(.text+0xe): undefined reference to `std::cout' 
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: test.cpp:(.text+0x13): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)' 
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccPv7MvI.o: in function `__static_initialization_and_destruction_0(int, int)': 
test.cpp:(.text+0x43): undefined reference to `std::ios_base::Init::Init()' 
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: test.cpp:(.text+0x58): undefined reference to `std::ios_base::Init::~Init()' 
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating DT_TEXTREL in a PIE 
collect2: error: ld returned 1 exit status

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<TCHAR>等。这是一个信号，表明代码最初用于UNICODE和多字节字符（或“窄”）构建。

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

这可以通过以下两种方式实现：；#定义UNICODE#定义UNICODE或在项目设置中；项目财产>常规>项目默认值>字符集或在命令行上；/DUNICODE/D-UNICODE

如果不打算使用UNICODE，请确保未设置定义，和/或在项目中使用了多字符设置，并始终应用。

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