在我的例子中，语法是正确的，但当一个类调用同一DLL中的第二个类时，我出现了错误。第二个类的CPP文件在visual studio中具有错误的财产->项类型，在我的例子中，它被设置为C/C++头，而不是正确的C/C++编译器，因此编译器在构建CPP文件时没有编译它，并导致错误LNK2019

下面是一个示例，假设语法正确，您应该通过更改财产中的项类型来获得错误

//class A header file 
class ClassB; // FORWARD DECLERATION
class ClassA
{
public:
ClassB* bObj;
ClassA(HINSTANCE hDLL) ;
//  member functions
}
--------------------------------
//class A cpp file   
ClassA::ClassA(HINSTANCE hDLL) 
{
    bObj = new ClassB();// LNK2019 occures here 
    bObj ->somefunction();// LNK2019 occures here
}
/*************************/

//classB Header file
struct mystruct{}
class ClassB{
public:
ClassB();
mystruct somefunction();
}

------------------------------
//classB cpp file  
/* This is the file with the wrong property item type in visual studio --C/C++ Header-*/
ClassB::somefunction(){}
ClassB::ClassB(){}

当包含路径不同时

当头文件及其关联的共享库（.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：改写第一节，使其更容易理解。请在下面评论，让我知道是否需要修复其他问题。谢谢

不同的架构

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

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

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

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

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

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

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

班级成员：

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

声明析构函数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 5.2.0中出现链接器错误的一个可能原因是现在默认选择了新的libstdc++库ABI。

如果您在std:：__cxx11命名空间或标记[abi:cx11]中获得了有关符号未定义引用的链接器错误，则可能表明您正在尝试将使用_GLIBCXX_USE_cxx11_abi宏的不同值编译的对象文件链接在一起。这通常发生在链接到使用旧版本GCC编译的第三方库时。如果无法使用新的ABI重建第三方库，则需要使用旧的ABI重新编译代码。

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