Static libraries are archives that contain the object code for the library, when linked into an application that code is compiled into the executable. Shared libraries are different in that they aren't compiled into the executable. Instead the dynamic linker searches some directories looking for the library(s) it needs, then loads that into memory. More then one executable can use the same shared library at the same time, thus reducing memory usage and executable size. However, there are then more files to distribute with the executable. You need to make sure that the library is installed onto the uses system somewhere where the linker can find it, static linking eliminates this problem but results in a larger executable file.

c++程序的构建分两个阶段

编译——生成目标代码(.obj) 链接——生成可执行代码(.exe或.dll)

静态库(.lib)只是一个.obj文件的包，因此不是一个完整的程序。它还没有经历构建程序的第二个(链接)阶段。另一方面，dll类似于exe，因此是完整的程序。

如果你构建了一个静态库，它还没有被链接，因此你的静态库的消费者将不得不使用与你使用的相同的编译器(如果你使用g++，他们将不得不使用g++)。

如果相反，您构建了一个dll(并且正确地构建了它)，那么您已经构建了一个所有消费者都可以使用的完整程序，无论他们使用哪种编译器。但是，如果需要跨编译器兼容性，则从dll导出有几个限制。

如果您的库将在几个可执行文件之间共享，那么将其动态化以减少可执行文件的大小通常是有意义的。否则，一定要让它是静态的。

使用dll有几个缺点。装载和卸载它有额外的开销。还有一个额外的依赖关系。如果您更改dll使其与执行表不兼容，则它们将停止工作。另一方面，如果您更改了静态库，则使用旧版本编译的可执行文件将不会受到影响。

如果库是静态的，则在链接时将代码链接到可执行文件中。这使您的可执行文件更大(如果您走动态路线)。

如果库是动态的，那么在链接时，对所需方法的引用将内置于可执行文件中。这意味着您必须发布可执行文件和动态库。您还应该考虑对库中代码的共享访问是否安全、首选加载地址以及其他事项。

如果你能接受静态库，那就使用静态库。

Ulrich Drepper关于“如何编写共享库”的论文也是一个很好的资源，详细介绍了如何最好地利用共享库，或者他所说的“动态共享对象”(DSOs)。本文主要讨论ELF二进制格式的共享库，但有些讨论也适用于Windows dll。

真正的权衡(在一个大型项目中)是在初始加载时间，库将在某个时间被链接，必须做出的决定是链接是否需要足够长的时间，以至于编译器需要咬紧牙关并提前完成，还是动态链接器可以在加载时完成。