【发布时间】：2011-02-08 14:40:11
【问题描述】：
静态库和共享库有什么区别？
我使用 Eclipse，并且有几种项目类型，包括静态库和共享库？一个比另一个有优势吗？
【问题讨论】：
-
维基百科有一个good description 区分静态、动态和共享库。
标签： c++ c shared-libraries static-libraries
【发布时间】：2011-02-08 14:40:11
【问题描述】：
共享库是 .so（或在 Windows .dll 或 OS X .dylib 中）文件。所有与库相关的代码都在这个文件中，并且在运行时被使用它的程序引用。使用共享库的程序只引用它在共享库中使用的代码。
静态库是 .a（或在 Windows 中为 .lib）文件。所有与库相关的代码都在这个文件中，并且在编译时直接链接到程序中。使用静态库的程序从静态库中获取它使用的代码的副本，并使其成为程序的一部分。 [Windows 也有用于引用 .dll 文件的 .lib 文件，但它们的作用与第一个相同]。
每种方法各有优缺点：
共享库减少了每个使用该库的程序中重复的代码量，从而使二进制文件保持较小。它还允许您将共享对象替换为功能等效的共享对象，但可能会增加性能优势，而无需重新编译使用它的程序。然而，共享库会为函数的执行带来少量额外成本，以及运行时加载成本，因为库中的所有符号都需要连接到它们使用的东西。此外，共享库可以在运行时加载到应用程序中，这是实现二进制插件系统的通用机制。
静态库会增加二进制文件的整体大小，但这意味着您无需携带正在使用的库的副本。由于代码在编译时连接，因此没有任何额外的运行时加载成本。代码就在那里。
个人比较喜欢共享库，但是在需要保证二进制没有太多可能难以满足的外部依赖的时候使用静态库，比如特定版本的C++标准库或者特定版本的Boost C++图书馆。
【讨论】：
-
“将共享对象替换为 ... 功能等效，但可能 [提高] 性能”：具体而言，API 语义使用中面向调用者的等效功能（应用程序编程接口：函数签名和变量包括类型），但实现方面的功能可能不止性能不同。：例如函数总是记录到文件 -> 也记录到 TCP 服务器：$MY_APP_LOG_SERVER 中预期的端口。
-
"[.sos incur a] 执行功能的小额额外成本" - 可能（如果功能组/排序已针对静态链接中的缓存局部性进行了优化，或者由于 OS/loader/compiler/architecture 中的异常，例如跨段/large-pointer perf. 惩罚），但在许多架构/编译器设置中，动态链接器会修补调用以创建完全相同的调用机操作码。
-
“由于代码是在编译时连接的，所以没有任何额外的运行时加载成本。代码就在那里。” - 是和否......如果执行需要，它都在可执行映像中准备好被分页，但是 - 从您的程序最近没有运行到缓存中的情况开始 - 使用共享库是可能的（有时可能或确定）操作系统、驱动程序或其他正在运行的程序已经加载了您的应用想要使用的同一个共享库，在这种情况下，它可能在缓存中并且您的程序启动和运行速度更快。
-
有些人没有提到的是，使用静态库，编译器知道您的应用程序需要哪些函数，然后可以通过仅包含这些函数来优化它。这可以大大减少库的大小，特别是如果您只使用一个非常大的库的一个非常小的子集！
-
这个答案可以更好地组织。为优缺点制作项目符号列表或制作表格以显示存在差异的每个维度的差异会很有帮助。
静态库就像书店，共享库就像……图书馆。使用前者，您可以获得自己的书籍/功能副本带回家；对于后者，您和其他所有人都去图书馆使用相同的书/功能。因此，任何想要使用（共享）库的人都需要知道它在哪里，因为您必须“去获取”这本书/功能。有了静态库，书/功能就归您所有，您可以将其保存在您的家/程序中，一旦拥有它，您就不必在乎何时何地获得它。
【讨论】：
简化：
- 静态链接：一个大型可执行文件
- 动态链接：一个小的可执行文件加上一个或多个库文件（Windows 上的 .dll 文件、Linux 上的 .so 或 macOS 上的 .dylib）
【讨论】：
对于静态库，代码由链接器从库中提取，并用于在您编译/构建应用程序时构建最终的可执行文件。最终的可执行文件在运行时对库没有依赖关系
对于共享库，编译器/链接器会在构建应用程序时检查您链接的名称是否存在于库中，但不会将它们的代码移动到应用程序中。在运行时，共享库必须可用。
C 编程语言本身没有静态库或共享库的概念——它们完全是一种实现特性。
就个人而言，我更喜欢使用静态库，因为它使软件分发更简单。然而，这种观点在过去已经流过很多（象征性的）鲜血。
【讨论】：
-
+1 表示“C 编程语言本身没有静态库或共享库的概念——它们完全是一种实现特性。”
-
嗨 anon / @Tiger，为什么你说“C 编程语言本身没有静态或共享库的概念——它们完全是一种实现特性。”？您能否详细解释一下或指出适当的参考资料？
-
@SunilShahu 程序的编译和链接方式取决于您使用的编译器和链接器，即语言的具体实现。语言规范一般不描述应该如何实现或构建语言，只描述功能、语法、语法等。
-
@SunilShahu 更明显的例子可能是 JavaScript，例如，规范 (EcmaScript) 描述了语言的特性，但提供 JS 解释器（浏览器引擎或 Node.js）的是不同的供应商。 js，例如）。另一方面，Python 编程语言有几个实现。官方是 CPython，但也有其他语言编写的。
静态库是作为应用程序的一部分编译的，而共享库不是。当您分发依赖于共享库的应用程序时，这些库，例如。需要在 MS Windows 上安装 dll。
静态库的优点是运行应用程序的用户不需要依赖项 - 例如。他们不必升级他们的DLL。缺点是您的应用程序体积较大，因为您将它与它需要的所有库一起提供。
除了导致更小的应用程序之外，共享库还为用户提供了使用自己的库的能力，也许是更好的库版本，而不是依赖于应用程序的一部分
【讨论】：
-
众所周知的DLL地狱
-
"静态库被编译为应用程序的一部分" ...静态库被编译为静态库并作为应用程序的一部分链接
共享库最显着的优势在于，无论有多少进程在使用该库，内存中只加载一份代码副本。对于静态库，每个进程都有自己的代码副本。这可能会导致大量内存浪费。
OTOH，静态库的一个优点是所有内容都捆绑到您的应用程序中。因此，您不必担心客户端的系统上会提供正确的库（和版本）。
【讨论】：
-
使用静态库时，磁盘和内存中的可执行映像更大。
-
没错，当我说一切都捆绑到您的应用程序中时，这就是我所暗示的。
-
此外，*nix 系统上的
.so文件有点像共享（动态）库。
除了所有其他答案之外，还没有提到的一件事是解耦：
让我谈谈我一直在处理的真实世界生产代码：
一个非常大的软件，由超过 300 个项目（使用 Visual Studio）组成，大部分构建为静态库，最后全部链接到一个巨大的可执行文件中，您最终会遇到以下问题：
-链接时间非常长。您可能会结束超过 15 分钟的链接，比如说 10 秒的编译时间 - 一些工具可以提供如此大的可执行文件，例如必须检测代码的内存检查工具。您可能会陷入被视为傻瓜的极限。
更多的问题是你的软件的解耦：在这个真实世界的例子中，每个项目的头文件都可以从任何其他项目中访问。因此，一位开发人员非常容易添加依赖项。它只是包括标题，因为最后的链接会找到符号。它以可怕的循环依赖和一团糟而告终。
使用共享库，这是一些额外的工作，因为开发人员必须编辑项目构建系统以添加依赖库。我观察到共享库代码倾向于提供更简洁的代码 API。
【讨论】：
-------------------------------------------------------------------------
| +- | Shared(dynamic) | Static Library (Linkages) |
-------------------------------------------------------------------------
|Pros: | less memory use | an executable, using own libraries|
| | | ,coming with the program, |
| | | doesn't need to worry about its |
| | | compilebility subject to libraries|
-------------------------------------------------------------------------
|Cons: | implementations of | bigger memory uses |
| | libraries may be altered | |
| | subject to OS and its | |
| | version, which may affect| |
| | the compilebility and | |
| | runnability of the code | |
-------------------------------------------------------------------------
【讨论】：
+---------------+---------------------------+------------------------------+
| properties | Static library | Shared library |
+===============+===========================+==============================+
| Linking time | It happens as the | Shared libraries |
| | last step of the | are added during |
| | compilation process. | linking process |
| | After the program | when executable |
| | is placed | file and libraries |
| | in the memory | are added to the memory. |
+---------------+---------------------------+------------------------------+
| Means | Performed by linkers | Performed by operating System|
+---------------+---------------------------+------------------------------+
| Size | Static libraries are | Dynamic libraries are |
| | much bigger in size, | much smaller, because |
| | because external | there is only one copy |
| | programs are built | of dynamic library |
| | in the executable file. | that is kept in memory. |
+---------------+---------------------------+------------------------------+
| External file | Executable file will | In shared libraries, |
| changes | have to be recompiled | no need to recompile |
| | if any changes were | the executable. |
| | applied to external files.| |
+---------------+---------------------------+------------------------------+
| Time | Takes longer to execute | It is faster |
| | because loading into the | because shared |
| | memory happens every time | library code is |
| | while executing. | already in the memory. |
+---------------+---------------------------+------------------------------+
| Compatibility | Never has a compatibility | Programs are dependent |
| | issue,since all code is | on having a compatible |
| | in one executable module. | library.Dependent program |
| | | will not work if library |
| | | gets removed from the system |
+---------------+---------------------------+------------------------------+
【讨论】：