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

我参与了一些关于Linux中的库的讨论，并想确认一些事情。

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:

根据我的理解(如果我错了请纠正我，稍后我会编辑我的帖子)，在构建应用程序时有两种使用库的方式:

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
(静态库。文件):在链接时，将整个库的副本放入最终的应用程序中，以便库中的函数始终对调用应用程序可用
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 runtime, where it is needed.
共享对象(。那么文件):在链接时，对象只是通过相应的header (.h)文件根据其API进行验证。这个库实际上直到运行时才被使用，在运行时需要它。

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 runtime, while DLL's must be opened first using the dlopen() call within the application.

我听说有些人区分共享对象和动态链接库(DLL)，尽管它们都是”。所以“文件。当涉及到Linux上的C/ c++开发或任何其他POSIX兼容的操作系统(例如:MINIX、UNIX、QNX等)时，共享对象和dll之间有什么区别吗?我被告知一个关键的区别(到目前为止)是共享对象只在运行时使用，而DLL的对象必须首先使用应用程序中的dlopen()调用打开。

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:

在这些术语提供给我的背景下，我发现了这些术语的细微差别，它们甚至可能只是我所在行业的俗语:

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.
共享对象:程序启动时自动链接到程序中的库，作为独立文件存在。该库包含在编译时的链接列表中(即:LDOPTS+=-lmylib用于命名为mylib.so的库文件)。库必须在编译时以及应用程序启动时出现。
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.
静态库:一个图书馆合并成实际的程序本身为一个(更大的)应用程序在构建时包含应用程序代码和库代码自动链接到一个程序时,程序是建立,最后二进制包含主程序和库本身存在作为一个独立的二进制文件。该库包含在编译时的链接列表中(即:LDOPTS+=-lmylib用于命名为mylib.a的库文件)。库必须在编译时出现。
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.
DLL:本质上与共享对象相同，但是并不包含在编译时的链接列表中，而是通过dlopen()/dlsym()命令加载库，以便在编译时不需要显示库以供程序编译。此外，库不需要在应用程序启动或编译时出现(必须)，因为它只需要在进行dlopen/dlsym调用时出现。
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.
共享存档:本质上与静态库相同，但使用“export-shared”和“-fPIC”标记编译。该库包含在编译时的链接列表中(即:LDOPTS+=-lmylibS用于命名为mylibS.a的库文件)。两者之间的区别是,这些额外的标记是必需的,如果一个共享对象或DLL想共享档案静态链接到自己的代码和能够共享对象的函数用于其他项目,而不是利用他们内部的DLL。当有人向您提供静态库时，并且您希望将其重新打包为SO时，这一点非常有用。库必须在编译时出现。

Additional Update

The distinction between "DLL" and "shared library" was just a (lazy, inaccurate) colloquialism in the company I worked in at the time (Windows developers being forced to shift to Linux development, and the term stuck), adhering to the descriptions noted above.

“DLL”和“共享库”之间的区别在我当时工作的公司中只是一个(懒惰的，不准确的)的口语用法(Windows开发人员*转向Linux开发，这个术语被卡住了)，遵循上面提到的描述。

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 the industry in general.

此外，在“共享档案”的情况下，在“共享档案”的情况下，“S”字后面的“S”只是在该公司使用的一种惯例，而不是在整个行业中。

4 个解决方案

#1

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').

我一直认为dll和共享对象只是不同的相同条款——Windows dll调用他们,而在UNIX系统*享对象,一般术语-动态链接库覆盖两个(甚至函数打开一个,所以在UNIX叫做dlopen后()“动态库”)。

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.

它们确实只在应用程序启动时被链接，但是您对头文件进行验证的想法是不正确的。头文件定义了要编译使用库的代码所需的原型，但是链接时链接器会查看库本身，以确保它所需要的函数实际上在那里。链接器必须在链接时间的某个地方找到函数体，否则会引起错误。它在运行时也这样做，因为正如您正确地指出的那样，库本身可能在编译程序之后发生了更改。这就是为什么ABI稳定性在平台库中如此重要，因为ABI更改会破坏针对旧版本编译的现有程序。

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.

静态库是成捆的对象文件的编译器,就像您正在构建自己的作为您的项目编译的一部分,所以他们被拉在链接器和美联储以完全相同的方式,和未使用的部分以完全相同的方式。

#2

148

A static library(.a) is a library that can be linked directly into the final executable produced by the linker,it is contained in it and there is no need to have the library into the system where the executable will be deployed.

静态库(A)是一个可以直接链接到链接器生成的最终可执行文件的库，它包含在它中，并且不需要将库放入可执行文件部署的系统中。

A shared library(.so) is a library that is linked but not embedded in the final executable, so will be loaded when the executable is launched and need to be present in the system where the executable is deployed.

共享库(so)是一个被链接的库，但没有嵌入到最终可执行文件中，因此当可执行文件被启动并需要在可执行文件部署的系统中出现时，它将被加载。

A dynamic link library on windows(.dll) is like a shared library(.so) on linux but there are some differences between the two implementations that are related to the OS (Windows vs Linux) :

windows上的动态链接库(.dll)类似于linux上的共享库(.so)，但与操作系统(windows vs . linux)相关的两个实现之间存在一些差异:

A DLL can define two kinds of functions: exported and internal. The exported functions are intended to be called by other modules, as well as from within the DLL where they are defined. Internal functions are typically intended to be called only from within the DLL where they are defined.

DLL可以定义两种函数:导出函数和内部函数。导出的函数将被其他模块调用，以及从定义它们的DLL中调用。内部函数通常只在定义它们的DLL中调用。

An SO library on Linux doesn't need special export statement to indicate exportable symbols, since all symbols are available to an interrogating process.

Linux上的SO库不需要特殊的导出语句来指示可导出的符号，因为查询过程可以使用所有符号。

#3

I can elaborate on the details of DLLs in Windows to help clarify those mysteries to my friends here in *NIX-land...

我可以向我在*NIX-land的朋友们详细阐述Windows上dll的细节，以帮助他们澄清那些谜团……

A DLL is like a Shared Object file. Both are images, ready to load into memory by the program loader of the respective OS. The images are accompanied by various bits of metadata to help linkers and loaders make the necessary associations and use the library of code.

DLL就像一个共享的对象文件。它们都是映像，可以由各自OS的程序加载器加载到内存中。这些图像附带各种元数据位，以帮助链接器和加载器进行必要的关联并使用代码库。

Windows DLLs have an export table. The exports can be by name, or by table position (numeric). The latter method is considered "old school" and is much more fragile -- rebuilding the DLL and changing the position of a function in the table will end in disaster, whereas there is no real issue if linking of entry points is by name. So, forget that as an issue, but just be aware it's there if you work with "dinosaur" code such as 3rd-party vendor libs.

Windows dll有一个导出表。导出可以按名称或表位置(数字)进行。后一种方法被认为是“老派”，而且更加脆弱——重新构建DLL并更改表中函数的位置将导致灾难，而如果入口点的链接是按名称进行的，则没有真正的问题。所以，不要把它当作一个问题，但要注意的是，如果你使用的是“恐龙”代码，比如第三方供应商libs。

Windows DLLs are built by compiling and linking, just as you would for an EXE (executable application), but the DLL is meant to not stand alone, just like an SO is meant to be used by an application, either via dynamic loading, or by link-time binding (the reference to the SO is embedded in the application binary's metadata, and the OS program loader will auto-load the referenced SO's). DLLs can reference other DLLs, just as SOs can reference other SOs.

Windows DLL是由编译和链接,就像对于一个EXE(可执行的应用程序),但DLL是为了不独立,就像一个应用程序使用的是,通过动态加载,或者通过链接时绑定(参考的是嵌入在应用程序二进制文件的元数据,和操作系统程序加载程序将自动负载所以引用的)。dll可以引用其他dll，就像SOs可以引用其他SOs一样。

In Windows, DLLs will make available only specific entry points. These are called "exports". The developer can either use a special compiler keyword to make a symbol an externally-visible (to other linkers and the dynamic loader), or the exports can be listed in a module-definition file which is used at link time when the DLL itself is being created. The modern practice is to decorate the function definition with the keyword to export the symbol name. It is also possible to create header files with keywords which will declare that symbol as one to be imported from a DLL outside the current compilation unit. Look up the keywords __declspec(dllexport) and __declspec(dllimport) for more information.

在Windows中，dll只能提供特定的入口点。这些被称为“出口”。开发人员可以使用特殊的compiler关键字使符号成为外部可见的(对其他链接器和动态加载程序来说)，也可以在创建DLL时使用的模块定义文件中列出导出。现代的做法是用关键词来装饰函数定义，导出符号名。也可以使用关键字创建头文件，这些头文件将声明该符号为从当前编译单元外部的DLL导入的一个符号。查找关键字__declspec(dllexport)和__declspec(dllimport)以获得更多信息。

One of the interesting features of DLLs is that they can declare a standard "upon load/unload" handler function. Whenever the DLL is loaded or unloaded, the DLL can perform some initialization or cleanup, as the case may be. This maps nicely into having a DLL as an object-oriented resource manager, such as a device driver or shared object interface.

dll的一个有趣特性是它们可以声明一个标准的“加载/卸载”处理程序函数。每当加载或卸载DLL时，DLL就可以执行一些初始化或清理工作，这是可能的。它很好地将DLL映射为面向对象的资源管理器，如设备驱动程序或共享对象接口。

When a developer wants to use an already-built DLL, she must either reference an "export library" (*.LIB) created by the DLL developer when she created the DLL, or she must explicitly load the DLL at run time and request the entry point address by name via the LoadLibrary() and GetProcAddress() mechanisms. Most of the time, linking against a LIB file (which simply contains the linker metadata for the DLL's exported entry points) is the way DLLs get used. Dynamic loading is reserved typically for implementing "polymorphism" or "runtime configurability" in program behaviors (accessing add-ons or later-defined functionality, aka "plugins").

当开发人员想利用一个早已建好的网络下部DLL时,她必须引用一个“出口库”(* . lib)创建DLL开发人员创建DLL,或她必须显式地在运行时加载DLL和请求的入口点地址的名字通过LoadLibrary()和GetProcAddress()机制。大多数时候，链接到LIB文件(它仅仅包含DLL导出的入口点的链接器元数据)是DLL使用的方式。动态加载通常用于在程序行为中实现“多态性”或“运行时可配置性”(访问附加组件或后期定义的功能，即“插件”)。

The Windows way of doing things can cause some confusion at times; the system uses the .LIB extension to refer to both normal static libraries (archives, like POSIX *.a files) and to the "export stub" libraries needed to bind an application to a DLL at link time. So, one should always look to see if a *.LIB file has a same-named *.DLL file; if not, chances are good that *.LIB file is a static library archive, and not export binding metadata for a DLL.

Windows操作方法有时会引起一些混乱;系统使用. lib扩展来引用两个常规静态库(归档文件，如POSIX *)。在链接时将应用程序绑定到DLL所需的“导出存根”库和文件。所以，我们应该经常看看a *。LIB文件有一个相同的名称*。DLL文件;如果没有的话，很有可能是*。LIB文件是一个静态库存档，而不是为DLL导出绑定元数据。

#4

You are correct in that static files are copied to the application at link-time, and that shared files are just verified at link time and loaded at runtime.

您是正确的，静态文件在链接时复制到应用程序，共享文件在链接时验证，在运行时加载。

The dlopen call is not only for shared objects, if the application wishes to do so at runtime on its behalf, otherwise the shared objects are loaded automatically when the application starts. DLLS and .so are the same thing. the dlopen exists to add even more fine-grained dynamic loading abilities for processes. You dont have to use dlopen yourself to open/use the DLLs, that happens too at application startup.

dlopen调用不仅适用于共享对象，如果应用程序希望在运行时代表其这样做，则在应用程序启动时自动加载共享对象。dll和。so是一样的东西。dlopen的存在是为了为进程添加更细粒度的动态加载能力。您不必使用dlopen来打开/使用dll，这在应用程序启动时也会发生。

#1

#2

148