在我的例子中，语法是正确的，但当一个类调用同一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(){}

编译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系统上也可以

链接在引用库的对象文件之前使用库

您正在尝试编译程序并将其与GCC工具链链接。链接指定了所有必要的库和库搜索路径如果libfoo依赖于libbar，那么链接会正确地将libfoo放在libbar之前。链接失败，对某些错误的引用未定义。但是所有未定义的东西都在你的头文件中声明#并且实际上是在您链接的库中定义的。

示例在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

例如1.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

一个涉及共享系统库的最小示例，即压缩库libz

例如2.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

示例2的一个变体涉及pkg配置：

$ 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配置变体：

$ gcc -o eg2 eg2.o $(pkg-config --libs zlib) 
$ ./eg2
1.2.8

解释

从这里开始，阅读是可选的。

默认情况下，GCC在您的发行版上生成的链接命令，在中从左到右使用链接中的文件命令行序列。当它发现一个文件引用了某个并且不包含其定义，to将搜索定义在更右边的文件中。如果它最终找到了定义解析引用。如果任何引用在结束时仍未解决，链接失败：链接器没有向后搜索。

首先，示例1，使用静态库my_lib.a

静态库是对象文件的索引存档。当链接器在链接序列中找到-lmy-lib，并指出这是指到静态库/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_库。因为在这一点上，它还没有看到eg1.o。您的程序尚未引用hw:it根本没有做任何引用，因为它做的所有引用在eg1.o中。

因此，链接器不会将my_lib.o添加到程序中，并且没有其他内容用于libmy_lib.a。

接下来，它找到eg1.o，并将其添加到程序中。中的对象文件链接序列总是添加到程序中。现在，该程序使对hw的引用，并且不包含hw的定义；但是链接序列中没有任何内容可以提供缺失释义对hw的引用最终无法解析，链接失败。

第二，示例2，使用共享库libz

共享库不是对象文件或类似文件的存档更像是一个没有主功能的程序而是公开它定义的多个其他符号程序可以在运行时使用它们。

今天，许多Linux发行版配置其GCC工具链，以便其语言驱动程序（GCC、g++、gfortran等）指示系统链接器（ld）根据需要链接共享库。你有一个这样的发行版。

这意味着当链接器在链接序列中找到-lz，并发现这是指到共享库（例如）/usr/lib/x86_64-linux-gnu/libz，它想知道它添加到程序中的任何尚未定义的引用是否具有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配置变体现在有了一个显而易见的解释。壳体膨胀后：

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系统链接静态和共享是很正常的不同的规则。链接序列中的静态库已链接但是共享库是无条件链接的。

这种行为在链接时是经济的，因为链接器不必考虑程序是否需要共享库：如果是共享库，大多数链接中的大多数库都是共享库。但也有缺点：-

这在运行时是不经济的，因为它会导致共享库与程序一起加载，即使不需要它们。静态库和共享库的不同链接规则可能会令人困惑对于不熟练的程序员，他们可能不知道-lfo是否在他们的联系中将解析为/some/where/libfoo.a或/some/wwhere/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':

另请参见

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

将相互依赖的库按错误的顺序排列只是一种方法在其中，您可以获取需要对即将到来的事物进行定义的文件在链接中晚于提供定义的文件。将库放在引用它们的对象文件是犯同样错误的另一种方式。

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

gcc的默认行为是所有符号都可见。但是，当使用选项-fvisibility=hidden构建转换单元时，只有标记为__attribute__（（可见性（“默认”））的函数/符号在生成的共享对象中是外部的。

您可以通过调用以下命令来检查要查找的符号是否为外部符号：

# -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类似，可以使用define标记公共函数，例如DLL_public定义为：

#define DLL_PUBLIC __attribute__ ((visibility ("default")))

DLL_PUBLIC int my_public_function(){
  ...
}

大致对应于Windows的/MSVC版本：

#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

跨模块.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
{
};

模板实现不可见。

非专用模板的定义必须对使用它们的所有翻译单位可见。这意味着不能分离模板的定义到实现文件。如果必须分离实现，通常的解决方法是在头的末尾包含一个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的定义移动到头文件或使用它的翻译单元可见的某个位置。

专用化模板可以在实现文件中实现，并且实现不必是可见的，但是必须事先声明专用化。

有关进一步的解释和另一种可能的解决方案（显式实例化），请参阅此问题和答案。