静态库(.a)和共享库(.so)之间的文件格式差异? [英] File format differences between a static library (.a) and a shared library (.so)?

问题描述

我知道关于共享库和静态库的用例有很多问题，这个问题与之无关.我问的是磁盘上存储的文件格式的差异.

I know that there are lots of questions about the use cases of shared vs static libraries, this question is not about that. I am asking about differences in file format stored on disk.

为什么问题是，两者之间有什么区别?还是它们完全相同，只是用法不同?

Why question is, what are the differences between the two? Or are they exactly the same, different only in terms of usage?

我被认为是不一样的，因为在共享库上运行'nm'需要-D标志.显然，它需要做一些不同的事情.为什么?

I am lead to believe that they are not the same, since running 'nm' on a shared library requires the -D flag. Clearly it needs to do something differently. Why?

它们都是ELF文件吗?

Are they both ELF files?

共享库可以包含一些依赖路径是唯一的区别吗?

Is the only difference that the shared library can contain some paths of dependencies?

推荐答案

静态库，例如 libfoo.a 不是任何可执行文件.它只是 unix ar 格式的索引存档.恰巧是 ELF 的其他文件目标文件.

A static library, e.g. libfoo.a is not an executable of any kind. It is simply an indexed archive in unix ar format of other files which happen to be ELF object files.

创建了一个静态库，就像任何存档一样:

A static library is created like any archive:

ar crs libfoo.a objfile0.o objfile1.0...objfileN.o

输出新的归档文件( c )libfoo.a，并插入目标文件( r )和索引已添加( s ).

outputs the new archive (c) libfoo.a, with those object files inserted (r) and index added (s).

您会听说程序中的链接 libfoo.a .这并不意味着 libfoo.a 本身链接到程序中或与程序链接.这意味着 libfoo.a 作为存档传递到链接器，可以从中提取并链接到该程序只是该程序需要的存档中的那些目标文件.因此，静态库的格式( ar 格式)只是一个目标文件链接器输入的捆绑格式:同样可能是其他捆绑方式格式对链接程序的任务没有任何影响，即消化一组目标文件和共享库，并生成程序或共享库，从他们. ar 格式是历史记录的选择.

You'll hear of linking libfoo.a in a program. This doesn't mean that libfoo.a itself is linked into or with the program. It means that libfoo.a is passed to the linker as an archive from which it can extract and link into the program just those object files within the archive that the program needs. So the format of a static libary (ar format) is just an object-file bundling format for linker input: it could equally well have been some other bundling format without any effect on the linker's mission, which is to digest a set of object files and shared libraries and generate a program, or shared library, from them. ar format was history's choice.

另一方面，共享库，例如 libfoo.so ，是一个ELF文件而不是任何档案.

On the other hand a shared library, e.g. libfoo.so, is an ELF file and not any sort of archive.

不要试图通过以下方式怀疑静态库是一种ELF文件:所有著名的ELF解析器- objdump ， readelf ， nm 将解析静态库.这些工具都知道静态库是ELF目标文件的归档文件，因此它们只是解析所有目标文件就像在命令行中列出了它们一样.

Don't be tempted to suspect that a static library is a sort of ELF file by the fact that all the well-known ELF-parsers - objdump, readelf, nm - will parse a static libary. These tools all know that a static library is an archive of ELF object files, so they just parse all the object files in the library as if you had listed them on the commandline.

在 nm 中使用 -D 选项只是指示工具选择仅动态符号表中的符号(如果有)，解析的ELF文件的数量-运行时链接程序可见的符号-无论是否从存档中解析它们.它是与 objdump -T 和 readelf --dyn-syms 相同.不是不是使用这些选项分析共享库中的符号所必需.如果您没有这样做，那么默认情况下，您只会看到 full 符号表.如果您在静态库上运行 nm -D ，则系统会提示您没有符号归档文件中的每个目标文件-同样，如果您为每个文件都运行了 nm -D 这些目标文件.这样做的原因是目标文件没有动态符号表:只有共享库或程序有一个.

The use of the -D option with nm just instructs the tool to select only the symbols that are in the dynamic symbol table(s), if any, of the ELF file(s) that it parses - the symbols visible to the runtime linker - regardless of whether or not they are parsed from within an archive. It's the same as objdump -T and readelf --dyn-syms. It is not necessary to use these options to parse the symbols from a shared library. If you don't do so, then by default you'll just see the full symbol table. If you run nm -D on a static library you'll be told no symbols, for each object file in the archive - likewise if you ran nm -D for each of those object files individually. The reason for that is that an object file hasn't got a dynamic symbol table: only a shared library or progam has one.

目标文件，共享库和程序都是ELF格式的变体.如果您对ELF变体感兴趣，那么这些就是您感兴趣的变体.

Object file, shared library and program are all variants of the ELF format. If you're interested in ELF variants, those are the variants of interest.

ELF格式本身是一项冗长而棘手的技术阅读，因此需要精确区分变体的背景.简介:ELF文件包含一个 ELF标头结构，其字段之一包含类型标识符文件作为目标文件，共享库或程序.当文件是程序或共享库，它还包含一个可选的 Program头表结构，其字段为运行时链接程序/加载程序提供参数它需要在一个进程中加载​​文件.就ELF结构而言，程序和共享库之间的差异很小:改变他们行为的详细内容从装载机中引出.

The ELF format itself is a long and thorny technical read and is required background for precisely distinguishing the variants. Intro: An ELF file contains a ELF header structure one of whose fields contains a type-identifier of the file as an object file, shared library, or program. When the file is a program or shared library, it also contains an optional Program header table structure whose fields provide the runtime linker/loader with the parameters it needs to load the file in a process. In terms of ELF structure, the differences between a program and a shared library are slight: it's the detailed content that makes the difference to the behaviour that they elicit from the loader.

要获取冗长而棘手的技术知识，请尝试可执行和可链接格式(ELF)

For the long and thorny technical read, try Excutable and Linkable Format (ELF)

这篇关于静态库(.a)和共享库(.so)之间的文件格式差异?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！