共享库是 .so(或 Windows .dll 或 OS X .dylib)文件。所有与库相关的代码都在这个文件中,并且在运行时被使用它的程序引用。使用共享库的程序只引用它在共享库中使用的代码。
静态库是 .a(或 Windows 中的 .lib)文件。所有与库相关的代码都在这个文件中,并且在编译时直接链接到程序中。使用静态库的程序从静态库中获取它使用的代码的副本,并使其成为程序的一部分。 [Windows 也有用于引用 .dll 文件的 .lib 文件,但它们的作用与第一个相同]。
每种方法都有优点和缺点:
共享库减少了每个使用该库的程序中重复的代码量,从而使二进制文件保持较小。它还允许您将共享对象替换为功能等效的共享对象,但可能会增加性能优势,而无需重新编译使用它的程序。然而,共享库会为函数的执行带来少量额外成本,以及运行时加载成本,因为库中的所有符号都需要连接到它们使用的东西。此外,共享库可以在运行时加载到应用程序中,这是实现二进制插件系统的一般机制。
静态库会增加二进制文件的整体大小,但这意味着您不需要携带正在使用的库的副本。由于代码在编译时连接,因此没有任何额外的运行时加载成本。代码就在那里。
个人比较喜欢共享库,但是在需要保证二进制没有太多可能难以满足的外部依赖的时候使用静态库,比如特定版本的C++标准库或者特定版本的Boost C++库。
静态库就像书店,共享库就像……图书馆。使用前者,您可以获得自己的书籍/功能副本带回家;对于后者,您和其他所有人都去图书馆使用相同的书/功能。因此,任何想要使用(共享)库的人都需要知道它在哪里,因为您必须“去获取”这本书/功能。使用静态库,书/功能是您自己的,您可以将它保存在您的家庭/程序中,一旦您拥有它,您就不会在乎何时何地获得它。
简化:
静态链接:一个大型可执行文件
动态链接:一个小的可执行文件加上一个或多个库文件(Windows 上的 .dll 文件、Linux 上的 .so 或 macOS 上的 .dylib)
对于静态库,代码由链接器从库中提取,并在您编译/构建应用程序时用于构建最终的可执行文件。最终的可执行文件在运行时不依赖于库
对于共享库,编译器/链接器会在构建应用程序时检查您链接的名称是否存在于库中,但不会将它们的代码移动到应用程序中。在运行时,共享库必须可用。
C 编程语言本身没有静态库或共享库的概念——它们完全是一种实现特性。
就个人而言,我更喜欢使用静态库,因为它使软件分发更简单。然而,这是过去流过大量(象征性)鲜血的观点。
静态库是作为应用程序的一部分编译的,而共享库不是。当您分发依赖于共享库的应用程序时,这些库,例如。需要安装 MS Windows 上的 dll。
静态库的优点是运行应用程序的用户不需要依赖项——例如,他们不必升级他们的 DLL。缺点是您的应用程序体积较大,因为您将它与它需要的所有库一起提供。
除了导致更小的应用程序之外,共享库还为用户提供了使用自己的库的能力,也许是更好的库版本,而不是依赖于应用程序的一部分
共享库最显着的优势是,无论有多少进程在使用该库,内存中都只加载了一份代码副本。对于静态库,每个进程都有自己的代码副本。这会导致显着的内存浪费。
OTOH,静态库的一个优点是所有内容都捆绑到您的应用程序中。因此,您不必担心客户端会在其系统上拥有正确的库(和版本)。
.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 |
+---------------+---------------------------+------------------------------+