共享对象（.so），静态库（.a）和DLL（.so）之间的区别？ [英] Difference between shared objects (.so), static libraries (.a), and DLL's (.so)?

问题描述

我参与了Linux中的图书馆的一些辩论，并希望确认一些事情。

这是对我的理解（请纠正我我错了，我会稍后编辑我的帖子），构建应用程序时有两种使用库的方法：

1. 静态库.a文件）：在链接时，将整个库的副本放入最终应用程序，以使库中的函数始终可用于调用应用程序。


2. 共享对象（。所以文件）：在链接时，对象刚刚通过对应的头（.h）文件对其API进行了验证。图书馆在运行时间之前并没有被实际使用，需要它。

静态库的明显优点是它们允许整个应用程序是独立的，而动态库的好处是可以替换.so文件（即：如果需要由于安全漏洞而需要更新），而不需要重新编译基础应用程序。

我听说有些人区分共享对象和动态链接库（DLL），即使它们都是.so文件。在Linux或任何其他符合POSIX的操作系统（即：MINIX，UNIX，QNX等）上开发C / C ++时，共享对象和DLL之间是否存在区别？我被告知，一个关键的区别（到目前为止），共享对象只是在运行时使用，而DLL必须首先使用应用程序中的dlopen（）调用。

最后，我也听到有些开发者提到共享档案，据我所知，这些也是静态库本身，但直接不被应用程序使用。相反，其他静态库将链接到共享存档，以将一些（但不是全部）功能/资源从共享存档导入正在构建的静态库。

感谢您提前协助。

更新

---

在提供这些条款的背景下，我发现了这些术语的微小差异，甚至可能只是我行业的口语化：

1. 共享对象：程序启动时自动链接到程序中的库，作为独立文件存在。该库在编译时包含在链接列表中（即：LDOPTS + = - lmylib，用于名为mylib.so的库文件）。 库必须在编译时出现，应用程序启动时才会出现。


2. 静态库：构建时被合并到实际程序本身的库包含应用程序代码的单个（较大的）应用程序和在程序构建时自动链接到程序中的库代码，并且包含主程序和库本身的最终二进制文件本身作为一个独立的二进制文件存在。该库在编译时包括在链接列表中（即：LDOPTS + = - lmylib，用于名为mylib.a的库文件）。


3. DLL：与共享对象基本相同，而不是在编译时被包含在链接列表中，该库通过 dlopen（） / dlsym（）命令加载，以便库不需要存在构建程序编译的时间。 此外，在应用程序启动或编译时，库不需要存在（必须），因为只需要在 dlopen / dlsym 调用。


4. 共享存档：与静态库基本相同，但是使用export-shared 和-fPIC标志。在编译时，该库被包含在链接列表中（即：LDOPTS + = - lmylib S 用于名为mylib的库文件 S .a）中。两者之间的区别在于，如果共享对象或DLL要将共享存档静态链接到其自己的代码中，并且能够使共享对象中的函数可用于其他程序，而不是仅使用它们，则需要此附加标志内部的DLL。这在有人为您提供静态库的情况下很有用，并且您希望将其重新包装为SO。

附加更新

DLL 和共享库之间的区别只是公司的口语化我当时在工作，遵守上述说明。

此外，尾随的 S 在图书馆名称之后，在共享档案的情况下只是该公司使用的惯例，而不是在整个行业。

解决方案

我一直认为DLL和共享对象只是不同的术语 - Windows将它们称为DLL，而在UNIX系统上它们是共享对象，通用术语 - 动态链接库 - 覆盖（即使在UNIX上打开.so的功能在动态库之后称为 dlopen（）。

他们确实只是在应用程序启动时链接，但是你的概念o f对头文件的验证是不正确的。头文件定义了为了编译使用库的代码而需要的原型，但是在链接时，链接器看到库本身，以确保其所需的功能实际上在那里。链接器必须在链接时找到函数体，否则会引发错误。它还在运行时这样做，因为正确地指出，自编译程序以来，库本身可能已经更改。这就是为什么ABI稳定性在平台库中如此重要，因为ABI的变化是打破了旧版本编译的现有程序。

静态库只是直接对象文件的束在编译器中，就像您正在构建自己作为项目编译的一部分，因此它们以完全相同的方式被拉入并馈送到链接器，未使用的位将以完全相同的方式丢弃。 p>

I have been involved in some debate with respect to libraries in Linux, and would like to confirm some things.

It is to my understanding (please correct me if I am wrong and I will edit my post later), that there are two ways of using libraries when building an application:

1. Static libraries (.a files): At link time, a copy of the entire library is put into the final application so that the functions within the library are always available to the calling application
2. Shared objects (.so files): At link time, the object is just verified against its API via the corresponding header (.h) file. The library isn't actually used until run time, where it is needed.

The obvious advantage of static libraries is that they allow the entire application to be self-contained, while the benefit of dynamic libraries is that the ".so" file can be replaced (ie: in case it needs to be updated due to a security bug) without requiring the base application to be recompiled.

I have heard some people make a distinction between shared objects and dynamic linked libraries (DLL's), even though they are both ".so" files. Is there any distinction between shared objects and DLLs when it comes to C/C++ development on Linux or any other POSIX compliant OS (ie: MINIX, UNIX, QNX, etc)? I am told that one key difference (so far) is that shared objects are just used at run time, while DLL's must be opened first using the dlopen() call within the application.

Finally, I have also heard some developers mention "shared archives", which, to my understanding, are also static libraries themselves, but are never used by an application directly. Instead, other static libraries will link against the "shared archives" to pull some (but not all) functions/resources from the shared archive into the static library being built.

Thank you all in advance for your assistance.

Update

---

In the context in which these terms were provided to me, I've found out the slight differences in these terms, which may even be just colloquialisms in my industry:

1. Shared Object: A library that is automatically linked into a program when the program starts, and exists as a standalone file. The library is included in the linking list at compile time (ie: LDOPTS+=-lmylib for a library file named mylib.so). The library must be present at compile time, and when the application starts.
2. Static Library: A library that is merged into the actual program itself at build time for a single (larger) application containing the application code and the library code that is automatically linked into a program when the program is built, and the final binary containing both the main program and the library itself exists as a single standalone binary file. The library is included in the linking list at compile time (ie: LDOPTS+=-lmylib for a library file named mylib.a). The library must be present at compile time.
3. DLL: Essentially the same as a shared object, but rather than being included in the linking list at compile time, the library is loaded via dlopen()/dlsym() commands so that the library does not need to be present at build time for the program to compile. Also, the library does not need to be present (necessarily) at application startup or compile time, as it is only needed at the moment the dlopen/dlsym calls are made.
4. Shared Archive: Essentially the same as a static library, but is compiled with the "export-shared" and "-fPIC" flags. The library is included in the linking list at compile time (ie: LDOPTS+=-lmylibS for a library file named mylibS.a). The distinction between the two is that this additional flag is required if a shared object or DLL wants to statically link the shared archive into its own code AND be able to make the functions in the shared object available to other programs, rather than just using them internal to the DLL. This is useful in the case when someone provides you with a static library, and you wish to repackage it as an SO. The library must be present at compile time.

Additional Update

The distinction between "DLL" and "shared library" was just a colloquialism in the company I worked in at the time, adhering to the descriptions noted above.

Additionally, the trailing "S" literal after the library name, in the case of "shared archives" was just a convention used at that company, and not in industry in general.

解决方案

I've always thought that DLLs and shared objects are just different terms for the same thing - Windows calls them DLLs, while on UNIX systems they're shared objects, with the general term - dynamically linked library - covering both (even the function to open a .so on UNIX is called dlopen() after 'dynamic library').

They are indeed only linked at application startup, however your notion of verification against the header file is incorrect. The header file defines prototypes which are required in order to compile the code which uses the library, but at link time the linker looks inside the library itself to make sure the functions it needs are actually there. The linker has to find the function bodies somewhere at link time or it'll raise an error. It ALSO does that at runtime, because as you rightly point out the library itself might have changed since the program was compiled. This is why ABI stability is so important in platform libraries, as the ABI changing is what breaks existing programs compiled against older versions.

Static libraries are just bundles of object files straight out of the compiler, just like the ones that you are building yourself as part of your project's compilation, so they get pulled in and fed to the linker in exactly the same way, and unused bits are dropped in exactly the same way.

这篇关于共享对象（.so），静态库（.a）和DLL（.so）之间的区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！