当前位置：文江博客话题详情

.a .o 和 .lo 文件之间的区别

发布于 2024-11-05 20:07:10 字数 72 浏览 0 评论 0原文

C 语言中 .a .o 和 .lo 文件有什么区别？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

偏闹i 2024-11-12 20:07:10

.o、.a、.lo 和 .so 之间的区别。

执行摘要

.o 通常是编译器发出的非 PIC 目标文件（在链接器阶段之前）。当与 exe 链接时，代码将包含在可执行文件中 - 我们在链接时绑定。
.a 通常是包含一个或多个 .o 文件 [非 PIC] 的存档库。当与 exe 链接时，存档中的特定“*.o”文件将被插入到可执行文件中。
.lo 通常是一个包含 PIC 代码的“库对象”，无论是使用 gcc -fPIC 手动编译还是使用 libtool 手动编译。
.so 文件是“共享对象”文件。它们包含 PIC 对象。

注意：

如果您需要静态可执行文件，请使用“.o”和“.a”文件。
如果您需要/想要动态可执行文件在运行时与库绑定，请使用 .lo 和 .so 文件。

简介

虽然我喜欢上面的答案，但它们并未涵盖 .a/archive 库形式。因此，在这里我将解决所有三个问题，并添加 .so 库格式。另外，本着 stackexchange 的精神，我将使用更多文本，以防链接损坏（请注意，我不需要此链接的参考链接）。

文件类型 .o

当编译 .o 文件时，它是一个目标文件，其中包含编译器为目标平台发出的目标代码。要创建 .o 文件：

gcc -c filename.c     <==== creates filename.o

请注意，此示例未创建位置无关代码 (PIC)。我们认为这是一个可能包含在静态库或可执行文件中的对象。也就是说，当我们将可执行文件与 .o 文件链接时，.o 文件中的代码将被插入到可执行文件中 --- 它是在构建时绑定的，而不是在运行时绑定的。这意味着可执行文件可以在不包含 .o 文件的情况下重新分发。警告：按照惯例，.o 文件被视为非 PIC。我们通常使用 .lo 扩展名命名 PIC 对象文件。

文件类型 .a

.a 文件类型是“归档”库。它包含一个或多个 .o 文件，通常用于创建静态可执行文件。

我们使用ar命令来操作存档库。下面的示例中，(1) 从 .o 文件创建存档库，然后 (2) 列出其中的内容。

创建库

$ ls *.o
a.o  b.o  c.o                 <=== the files going in the archive

$ ar q libmyStuff.a *.o       <=== put *.o files in an archive (or new one)
ar: creating libmyStuff.a    

$ ls *.a                      <=== just show the library created
libmyStuff.a

显示存档库的内容

$ ar t libmyStuff.a
a.o
b.o
c.o

文件类型 .lo

.lo 的使用是一种惯例，通常用于与位置无关的对象文件。在当前目录中，libtoolcompile 命令创建一个 .lo 文件和一个 .o 文件，一个包含 PIC 代码，一个不包含 PIC 代码。请参阅下面的输出：

$ libtool compile gcc -c a.c
libtool: compile:  gcc -c a.c  -fPIC -DPIC -o .libs/a.o  <== PIC code
libtool: compile:  gcc -c a.c -o a.o >/dev/null 2>&1     <== Not-PIC code

$ ls a.lo a.o
a.lo  a.o       <=== a.lo contains the PIC code.

另请注意，.libs 子目录是使用其中的ao 创建的。尽管名称如此，但该文件是 PIC 代码。 Libtool 将此文件移至当前目录，并将扩展名更改为 .lo。

您始终可以在编译时通过使用 gcc 的 PIC 选项来手动创建 .lo 文件。将生成的 .o 文件移动到 .lo 扩展名。

文件类型 .so

按照约定，.so 意味着“共享对象”库文件。我们将 PIC 目标文件放入共享库中。与 .o 和 .a 文件不同，当我们链接 .so 文件时，代码不会包含在生成的编译文件中。也就是说，我们使用运行时绑定（如 .lo 情况）。运行时绑定有不止一种形式，但我们不会在这里讨论。

Difference Between .o, .a, .lo and .so.

Executive Summary

.o is typically a non-PIC object file emitted by the compiler (before linker stage) When linked with an exe, the code will be included in the executable -- we bind at link time.
.a is typically an archive library containing one or more .o files [non-PIC]. When linked with an exe, the particular "*.o" files in the archive will be inserted into the executable.
.lo is generally a "library object" that contains PIC code whether manually compiled with gcc -fPIC or using libtool.
.so files are "shared object" files. They contains PIC objects.

Note:

If you need static executables then use ".o" and ".a" files.
If you need/want dynamic executables the bind with libraries at run time, use .lo and .so files.

Introduction

While I like the answers above, they do not cover the .a/archive library form. So here I will address all three with a bonus of adding in a .so library format, as well. Also, in the vein of stackexchange, I will use more text in case links get broken (note that I did not need reference links for this one).

Filetype .o

When compiling a .o file is an object file containing the compiler emitted object code for the target platform. To create a .o file:

gcc -c filename.c     <==== creates filename.o

Note that this example did not create Position Independent Code (PIC). We consider this an object for possible inclusion in a static library or executable. That is, when we link an executable with a .o file, the code in the .o file is inserted into the executable --- it is bound at build time, not at run time. That means the executable can be redistributed without including the .o file. Caveat: it is convention that the .o file is considered non-PIC. We typically name PIC object files with a .lo extension.

Filetype .a

The .a file type is an "archive" library. It contains one or more .o files and it is typically used to for creating static executable files.

We use the ar command to manipulate archive libraries. Below in an example that (1) creates an archive library from .o files then (2) lists the contents of one.

Create the Library

$ ls *.o
a.o  b.o  c.o                 <=== the files going in the archive

$ ar q libmyStuff.a *.o       <=== put *.o files in an archive (or new one)
ar: creating libmyStuff.a    

$ ls *.a                      <=== just show the library created
libmyStuff.a

Display the Contents of an Archive Library

$ ar t libmyStuff.a
a.o
b.o
c.o

Filetype .lo

The use of .lo is a convention that is often used for position independent object files. In the current directory the libtool compile command creates both a .lo file and a .o file, one with PIC code and one without PIC code. See the output below:

$ libtool compile gcc -c a.c
libtool: compile:  gcc -c a.c  -fPIC -DPIC -o .libs/a.o  <== PIC code
libtool: compile:  gcc -c a.c -o a.o >/dev/null 2>&1     <== Not-PIC code

$ ls a.lo a.o
a.lo  a.o       <=== a.lo contains the PIC code.

Also note that the .libs subdirectory was created with a.o in it. This file is PIC code, despite the name. Libtool moved this file to the current directory and changed the extension to .lo.

You can always manually create .lo files simply by using the PIC option(s) to gcc when you compile. Move the resulting .o files to .lo extension.

Filetype .so

By convention .so implies a "shared object" library file. We put PIC object files into shared libraries. In contract to .o and .a files, when we link with .so files the code is not included in the resulting compiled file. That is we use run time binding (as in the .lo case). There is more than one form of runtime binding, but we won't go into that here.

回复收藏 0 原文