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

问题描述

我一直参与相对于Linux的图书馆一些争论，想确认一些事情。

这是我的理解（请纠正我，如果我错了，以后我会编辑自己的帖子），有构建应用程序时使用的库两种方式：

1. 静态库（.a文件）：在链接时，使库中的功能都可以调用应用程序的整个库的副本放入最终的应用程序


2. 共享对象（.so文件）：在链接时，对象只是通过相应的头文件（.h）文件验证对其API。该库没有实际使用，直到运行时，在需要的地方。

静态库的明显优点是，它们允许整个应用程序是自包含的，而动态库的好处是，。所以文件可以被替换（即：在情况下，它需要由于更新而不需要基本应用程序安全漏洞）进行重新编译。

我听到有些人做共享对象和动态链接库之间的区别（DLL的），即使它们都。所以文件。是否有共享对象和DLL之间的任何区别，当涉及到C / C ++开发在Linux或任何其他POSIX兼容的操作系统（如：MINIX，UNIX，QNX等）？有人告诉我，一个关键的区别（到目前为止）是共享对象只是用来在运行时，而DLL的必须先​​使用dlopen（）的应用程序中调用打开。

最后，我也听到一些开发商提起共享档案，对此，我的理解，也是静态库本身，而是从不直接使用的应用程序。相反，其他的静态库都会连接到共享档案，从共享归档拉一些（但不是全部）功能/资源转化为静态库正在建设中。

感谢大家提前对您的帮助。

更新：

---

在这些条款提供给我的背景，我发现了在这些方面的细微差异，甚至可能只是在我的行业俗语：

1. 共享对象：在程序启动时，并存在作为一个独立的文件，它会自动链接到程序库。该库包含在编译时链接列表（即：LDOPTS + = - lmylib一个库文件名为mylib.so）。 磁带库必须在编译时present，当应用程序启动。


2. 静态库：被合并到实际的程序本身在构建时为包含应用程序code和库code，它会自动链接到一个程序中的程序时，一个单一的（大）应用程序库是建造，同时含有主程序和本身存在作为单个独立的二进制文件库中的最终二进制。该库包含在编译时链接列表（即：LDOPTS + = - lmylib一个库文件名为mylib.a中）。 磁带库必须在编译时present。


3. DLL：基本上是一样的共享对象，而不是包含在编译时链接列表，该库是通过的dlopen（）加载 / 则dlsym（）命令，使该库并不需要是在构建时的程序编译present。 同时，图书馆并不需要是present（必须）在应用程序启动或编译时，因为它只需要在此刻的dlopen / 则dlsym 调用的。


4. 共享归档：基本上是一样的静态库，但与出口共享和-fPIC标志编译。该库包含在编译时链接列表（即：LDOPTS + = - lmylib 取值名为MYLIB库文件取值 .a）中。两者之间的区别在于，如果一个共享对象或DLL想要共享归档静态链接到它自己的code，并能够使功能提供给其他的程序的共享对象，而不是此附加标志是必需只是使用它们的内部到该DLL。这是当有人为您提供了静态库的情况下非常有用，并且希望重新包装为SO。 磁带库必须在编译时present。

解决方案

我一直认为，DLL和共享对象是同样的东西只是不同的术语 - Windows调用DLL的他们，而在UNIX系统上他们共享对象与一般的名词 - 动态链接库 - 涵盖（甚至是函数打开UNIX上的。所以被称为的dlopen（）后'动态库'）

他们确实是只有在应用程序启动的联系，但是你对头文件验证的概念是不正确。头文件定义了需要以编译code，它使用库原型，但是在链接时，链接器看起来库本身内，以确保其所需的功能实际上是在那里。链接器在链接时某处找到函数体或它会引发错误。它也不会在运行时，因为当你正确地指出了图书馆本身可能已经改变，因为该程序被编译。这就是为什么ABI稳定在平台库很重要，因为ABI变化就是打破了老版本编译的现有方案。

静态库只是捆绑对象文件直出的编译器，就像你正在构建自己作为你的项目的编译的一部分的人，使他们获得在拉并送入连接器以完全相同的方式，而未使用的位被丢弃在完全相同的方式

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.

解决方案

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屋！