一个共享对象（SO）和一个动态链接库（DLL）在体系上有什么区别？ [英] Architecturally what is the difference between a shared object (SO) and a dynamic link library (DLL)?

问题描述

问题在于标题：在操作系统级实现方面，共享对象和dll的共享方式有何不同？

The question is pretty much in the title: in terms of OS-level implementation, how are shared objects and dlls different?

我问这个原因是因为我最近阅读了关于扩展Python的此页面，其中指出：

The reason I ask this is because I recently read this page on extending Python, which states:

Unix和Windows使用完全不同的范例来运行代码加载。在您尝试构建可以动态加载的模块之前，请注意系统的工作原理。

Unix and Windows use completely different paradigms for run-time loading of code. Before you try to build a module that can be dynamically loaded, be aware of how your system works.

在Unix中，共享对象（.so）文件包含由程序使用，以及它期望在程序中找到的函数和数据的名称。当文件加入程序时，对文件代码中的这些功能和数据的所有引用都将更改为指向程序中将功能和数据放入内存的实际位置。这基本上是一个链接操作。

In Unix, a shared object (.so) file contains code to be used by the program, and also the names of functions and data that it expects to find in the program. When the file is joined to the program, all references to those functions and data in the file’s code are changed to point to the actual locations in the program where the functions and data are placed in memory. This is basically a link operation.

在Windows中，动态链接库（.dll）文件没有悬挂引用。相反，对功能或数据的访问通过查找表。因此，DLL代码不必在运行时被修复以引用程序的内存;相反，代码已经使用了DLL的查找表，并且在运行时修改查找表以指向函数和数据。

In Windows, a dynamic-link library (.dll) file has no dangling references. Instead, an access to functions or data goes through a lookup table. So the DLL code does not have to be fixed up at runtime to refer to the program’s memory; instead, the code already uses the DLL’s lookup table, and the lookup table is modified at runtime to point to the functions and data.

有人可以详细说明一下吗？具体来说，我不知道我理解共享对象的描述，包含对他们期望找到的内容的引用。同样，一个DLL听起来和我一样的机制。

Could anyone elaborate on that? Specifically I'm not sure I understand the description of shared objects containing references to what they expect to find. Similarly, a DLL sounds like pretty much the same mechanism to me.

这是一个完整的解释，正在发生什么？有更好的吗？有没有什么区别？

Is this a complete explanation of what is going on? Are there better ones? Is there in fact any difference?

我知道如何链接到一个DLL或共享对象和几个机制（.def listing，dllexport / dllimport）for编写DLL，所以我明确地不寻找一个如何在这些领域;我更感兴趣的是在后台发生了什么。

I am aware of how to link to a DLL or shared object and a couple of mechanisms (.def listings, dllexport/dllimport) for writing DLLs so I'm explicitly not looking for a how to on those areas; I'm more intrigued as to what is going on in the background.

（编辑：另一个明显的点 - 我知道他们在不同的平台上工作，使用不同的文件类型（ELF对PE）是ABI不兼容的...）

( another obvious point - I'm aware they work on different platforms, use different file types (ELF vs PE), are ABI-incompatible etc...)

推荐答案

一个Dll几乎是相同的机制使用.so或.dylib（MacOS）文件，所以很难解释什么是差异。

A Dll is pretty much the same mechanism as used by .so or .dylib (MacOS) files, so it is very hard to explain exactly what the differences are.

核心区别在于默认可见从每种类型的文件。 .so文件导出语言（gcc）级别的链接 - 这意味着（默认情况下）所有C& c ++符号是extern可用于链接.so被拉入
这也意味着，因为解析.so文件本质上是一个链接步骤，加载程序不关心哪个.so文件是一个符号来自它只是按照.a文件遵循的通常的链接步骤规则按照某些顺序搜索指定的.so文件。另一方面，Dll文件是一个操作系统功能。

The core difference is in what is visible by default from each type of file. .so files export the language (gcc) level linkage - which means that (by default) all C & c++ symbols that are "extern" are available for linking when .so's are pulled in. It also means that, as resolving .so files is essentially a link step, the loader doesn't care which .so file a symbol comes from. It just searches the specified .so files in some order following the usual link step rules that .a files adhere to.

，完全独立于语言的链接步骤。 MSVC使用.lib文件链接静态和动态库（每个dll文件生成一个用于链接的配对的.lib文件），因此生成的程序一旦建立就完全链接（从语言为中心的角度） 。

Dll files on the other hand are an Operating system feature, completely separate to the link step of the language. MSVC uses .lib files for linking both static, and dynamic libraries (each dll file generates a paired .lib file that is used for linking) so the resulting program is fully "linked" (from a language centric point of view) once its built.

然而，在链接阶段，在表示Dll的lib中解析了符号，允许链接器在PE文件中构建包含明确列表的dll的导入表和每个dll中引用的入口点。在加载时，Windows不必执行链接来解析共享库中的符号：该步骤已经完成 - Windows加载器只是加载dll并直接挂接这些函数。

During the link stage however, symbols were resolved in the lib's that represents the Dlls, allowing the linker to build the import table in the PE file containing an explicit list of dlls and the entry points referenced in each dll. At load time, Windows does not have to perform a "link" to resolving symbols from shared libraries: That step was already done - the windows loader just loads up the dll's and hooks up the functions directly.

这篇关于一个共享对象（SO）和一个动态链接库（DLL）在体系上有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！