需要考虑的一些拼写错误：（我作为初学者经常遇到）

如果您使用的是类：请检查您是否没有在定义函数的cpp文件中的函数名之前忘记“classname:：”。如果使用forward声明：请确保声明正确的类型。例如：如果要转发声明“结构”，请使用“结构”而不是“类”。

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

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

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

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

班级成员：

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

声明析构函数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允许在类内初始化所有静态常量数据成员。

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

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

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

当包含路径不同时

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

链接器是如何工作的？链接器通过比较函数声明（在头中声明）和函数定义（在共享库中）的签名来匹配它们。如果链接器找不到完全匹配的函数定义，则可能会出现链接器错误。

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

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

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

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

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

繁荣你得到了一个链接器错误，你不知道它为什么会失败。原因是公共库使用相同includecommon_math.h的不同版本（我在本例中通过包含不同的路径来说明这一点，但可能并不总是那么明显。可能编译器设置中的包含路径不同）。

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

调试链接器

如果您正在使用Visual Studio，DUMPBIN是您的朋友。我相信其他编译器也有类似的工具。

过程如下：

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

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

编辑1：改写第一节，使其更容易理解。请在下面评论，让我知道是否需要修复其他问题。谢谢