如何解决为什么静态和动态可链接库不同?
| 如果它们都包含编译后的代码,为什么我们不能在运行时加载“ static”文件,为什么不能在编译时链接到动态库?为什么需要使用单独的格式来包含“独立”代码?有什么需要保证区别的地方要存储什么?解决方法
从静态库包含目标文件库的意义上来说,它们是真正的库。每个目标文件通常是从单个源文件创建的,并且包含机器代码以及有关代码所需数据的信息。在链接步骤中,链接器将选择必要的目标文件并将其组合为可执行文件。
机器代码的重要部分是跳转,调用和数据指针必须包含实际的内存地址。但是,如果目标文件需要调用另一个目标文件中的另一个函数,则只能使用符号来引用该函数。当链接器将目标文件组合为可执行代码时,符号引用将被解析并转换为实存储器地址。
动态库是可执行代码,可以将其加载到内存中并立即执行。在某些操作系统上,可能还有一个附加步骤,其中通过将可执行代码移动到另一个位置来重新编码代码,这需要将代码内的所有绝对地址移位固定量。此操作仍然比合并目标文件和解析链接程序完成的符号要快得多。
把它们加起来:
静态库包含一些使用符号来引用其他可执行代码的可执行代码
动态库(和可执行文件)包含现在放置在固定位置的可执行代码,使这些符号可以替换为实际内存地址
如果您曾经尝试链接大小合理的项目,则您会注意到,它花费的时间并不短,可能比等待启动应用程序要长。这种解释说明了为什么您不能执行静态库。动态库已经过优化和剥离,除可执行代码外不包含任何内容,这使它们不适合用作静态库。
, 目标文件中的代码未链接。它包含对尚未解决的外部函数的隐式引用。
链接目标文件以创建DLL时,链接程序将遍历所有这些外部引用,并找到可以满足它们的其他库(静态或动态)。通过将函数的主体(或任何主体)包含到DLL中,可以解析对静态库中名称的引用。如果它引用动态库,则DLL和引用函数的名称都包含在DLL中。
最终,没有理由一定是这种情况。从理论上讲,您可以编写加载程序以在每次加载文件时执行所有这些操作。基本上,这只是一种优化:链接器完成了工作中相对较慢的部分。保留了对DLL的引用,但已解决到使加载程序查找并加载目标文件(如有必要)并解析引用的函数相当快的地步。链接器执行其工作时,它会扫描一长串的定义列表以查找您关心的定义,从而做得更多,这要慢得多。
,注意:以下答案不是平台无关的,而是特定于基于ELF的系统和其他一些类似的系统。其他人可以填写其他系统的详细信息。
什么是静态库?
静态库是存档中“ 0”个文件的集合。每个文件都可以包含对未定义符号的引用,链接器必须对此文件进行解析,例如,您的库可能具有对“ 1”的引用。该库未提供有关在何处可以找到ѭ1indication的任何指示,希望链接器在要求链接的其他库之一中找到它。
假设您的库包含以下代码:
read_png.o
write_png.o
read_jpg.o
write_jpg.o
resize_image.o
handle_error.o
如果应用程序仅使用read_png
和write_png
,则其他代码段将不会加载到可执行文件中(handle_error
除外,from6ѭ从ѭ4called和write_png
调用)。
我们无法在运行时加载静态库,因为:
链接器不知道在哪里可以找到外部对象,例如printf
。
会很慢。动态库已针对快速加载进行了优化。
静态库没有名称空间的概念。我无法定义自己的handle_error
,因为它会与库的定义冲突。
什么是动态库?
ELF系统上的动态库是与可执行文件相同类型的对象。它还导出更多符号,可执行文件只需要导出_start
。动态库经过优化,因此可以将整个对象直接映射到内存中。
如果您在动态库中调用了“ 1”,那么除了静态库的要求之外,还有一些其他要求:
您必须指定哪个库具有printf
。
您必须以一种特殊的方式调用该函数,以使链接器可以插入printf
的地址。在静态库中,链接器只能修改您的代码并直接插入地址,但是共享库则无法实现。
我们不想使用动态库静态链接,因为:
我们不能仅链接动态库的一部分。即使我们的可执行文件从不调用ѭ15,它也会被包含在内,因为动态库是全有还是全无。
即使很小,函数调用的额外开销也是浪费的。
摘要
编译看起来像这样:
Source ==compile==> Object ==link==> Executable / Shared Library
静态库是一个充满了尚未链接对象的归档文件。还有很多工作要做。
共享库是链接的最终产品,可以随时加载到内存中。
静态库是最早发明的。如果两者是同时发明的,那么它们可能会更加相似。
, 根本没有理由不能将静态库(.a
)文件用作动态库,无法在程序启动时甚至在运行时动态加载和链接它们。但是,它们尚未经过专门编译并准备在任意地址运行内存映射(甚至对齐不一定正确!),因此加载程序代码将不得不分配内存,从.a
文件中读取必要的对象到此文件中。内存,并对其进行重大修改。当然,这些内存都不是可共享的。因此,这可能是一个非常糟糕的主意...
,静态lib == tarball,而动态==连续图像部分链接
静态库只是.o or
.obj`文件的tarball1。当链接一个可执行文件时,将被引用的模块(以及它们所引用的模块,然后是它们所引用的模块,然后...等等)从静态库中复制出来并粘贴到主程序的末尾。这整个东西作为单个OS“对象”分页到内存中。
动态库只吸收静态库的所有元素,将它们链接在一起(解决壁间关系),然后将整个对象映射到内存中。 (按需分页可以使部分内存存在。)在启动动态程序时需要一定程度的摆弄,以便将主程序(将“静态”链接到其自身模块中)连接到该库上。在系统范围内共享。有时,这种摆弄会延迟每个链接元素,直到发出给定调用为止。在一个非常广泛的,概念过度的扫描中,可以将静态链接归类为渴望加载,而将动态链接归类为延迟加载。
静态库有优缺点。
✚没有DLL的地狱(aka依赖地狱)
for内存占用空间小得多,适用于小型运行时混合流程
−对于不同程序的大型运行时混合处理,内存占用量更大
−进程之间不能共享任何库代码内存,除非它们正在运行同一程序
−由于printf等在每个图像中一遍又一遍地重复,因此大量程序(例如Linux / Windows / Mac足迹)占用了大量空间。
−很难甚至不可能修复源自库的安全漏洞
−很难甚至不可能单独更新库
alone很难甚至不可能独自更新一个库并破坏程序
1.实际上,它们不是tar(1)格式,而是相关的。
, 区别在于:
静态库以及编译和链接
动态库已链接
参考文献
避免LD_LIBRARY_PATH
共享库HOWTO
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。