静态库与动态库答案

【问题标题】：Static Vs Dynamic libraries静态库与动态库
【发布时间】：2011-11-05 02:21:44
【问题描述】：

我已阅读有关静态和动态库的信息。我的问题不大具体

dlopen dlclose：

Benifit of dlopen is  we can start the EXE with out
loading the necessary libraries at the begining. Only when we
need we will load the libratries and unload it from the memory.

这是动态链接库的行为。

我的问题是我是否链接库 libUtlities

ld -o EXE main.o -lUtilities

当我运行 EXE 时，libUtlities 会先加载到内存中我首先使用那里的功能

which i observed in dbx (Solaris debugger)
But will not contribute to the size of the EXE.

1.那么是静态链接还是动态链接。 ?

【问题讨论】：

第一个引用是相当虚假的。如果有人为此目的使用动态加载，他们只是让他们的代码变得不必要地丑陋和复杂。动态加载的唯一合法目的是制作一个支持加载新代码的程序在程序本身链接/分发后或由第三方进入程序。

标签： c++ c dynamic static-libraries dlopen

【解决方案1】：

不幸的是，“静态”和“动态”这两个词被过度使用方式，尤其是在 C 和 C++ 中。所以，我更喜欢以下术语：

链接时链接，也称为“静态链接”：所有符号都在链接时从静态库中解析。结果是一个单一的、静态链接的可执行文件，没有加载时依赖项。
加载时链接：这是现代平台上的标准做法，在共享库（Unix）或不幸命名的动态链接库中查找未解析的符号（ DLLS），并且仅在链接时记录引用，符号的实际解析和代码加载发生在加载时。

这会产生一个“动态链接”的可执行文件，该可执行文件必须使用 loader 加载（例如 Linux 上的 ld.so）。加载是操作系统的一部分，通常对用户透明，尽管它是开放的（例如在 Linux 上使用ldd）。所有共享库必须在加载时可用，否则程序将无法启动。
运行时链接，又名“动态链接”：没有未解析的符号；相反，运行时动态决定使用dlopen() 或LoadLibrary() 在共享/动态库中查找符号。找不到符号是可处理的运行时条件，不是错误。这种技术通常用于插件架构，并在 Windows 上用于代码注入。

但是请注意，Linux 的共享对象和 Windows 的 DLL 之间存在根本的技术差异，它们不仅仅是同一个名称不同的东西。然而，两者都可以用于加载时链接和运行时链接。

【讨论】：

您似乎混合了共享库和静态/动态链接库。可以有静态链接的共享库。你能解释一下为什么这个区别在这里不重要吗？
@Johannes：我到底在哪里混淆了这些？我想这些定义是递归应用的，所以共享库本身可以是单片的（静态链接的），也可以是独立的加载时依赖项，但这不应该与我所说的相矛盾，不是吗？
可以将程序foo与libc链接，这样foo中的所有名称都链接到libc中函数的静态已知地址，固定加载地址为@987654329 @。那是到共享库 (libc) 的静态链接（并且无法使用像 LD_PRELOAD 这样的技巧）。但是foo 仍然存在加载时依赖关系（如果我们从磁盘中删除libc，运行时会失败，因为无法从libc 加载代码）。您说“链接时链接，......结果是一个单一的、静态链接的可执行文件，没有加载时依赖项。”。还是我错过了什么？
@Johannes：啊，我确实说过，我不知道你可以这样做。你会怎么做？这是典型的情况吗？我很高兴修改那段！

【解决方案2】：

这是动态链接。与dlopen dlclose 无关。通过dlopen，您正在手动打开动态库并调用从中导出的函数。通过动态链接，所有这些工作都由链接器完成。静态链接是针对静态库（.a 文件）的链接。通过静态链接，库中的代码被链接到你的 exe 中，增加了它的大小。

【讨论】：

@ks 感谢回复：所以除了 dlopen dlclose 情况，当我们启动 EXE 时，所有依赖库都会占用内存。
所有动态链接的库（ldd报告的那些）将与EXE一起加载到内存中。静态链接的库已经在 EXE 中。 dlopen打开的库在dlopen之后直接加载到mem，dlclose之后直接卸载。