.a .o和.lo文件之间的区别
C中.a .o和.lo文件有什么区别？
“.lo”文件是一个库对象 ，可以被构build到一个共享库中，“.o”文件是一个标准的对象文件
.lo文件是 Libtool 对象 ，Libtool使用这个对象来确定可以将哪个对象文件构build到共享库中
.o，.a，.lo和.so之间的区别
执行摘要
- .o通常是编译器发出的非PIC对象文件（在链接器阶段之前）当与一个exe链接时，代码将包含在可执行文件中 – 我们在链接时绑定。
- .a通常是一个包含一个或多个.o文件[非PIC]的存档库。 当与一个exe链接时，档案中的特定“* .o”文件将被插入到可执行文件中。
- .lo通常是包含PIC代码的“库对象”，无论是使用gcc -fPIC还是使用libtool进行手动编译。
- .so文件是“共享对象”文件。 它们包含PIC对象。
注意：
- 如果您需要静态可执行文件，则使用“.o”和“.a”文件。
- 如果您需要/想要在运行时dynamic执行与库的绑定，请使用.lo和.so文件。
介绍
虽然我喜欢上面的答案，但不包括.a / archive library表单。 所以在这里，我将用一个.so库格式的join来解决所有这三个问题。 而且，在stackexchange的情况下，我将使用更多的文本，以防链接被破坏（请注意，我不需要这个链接）。
文件types.o
当编译一个.o文件是一个包含编译器发出的目标平台的目标代码的目标文件。 创build一个.o文件：
gcc -c filename.c <==== creates filename.o
请注意，此示例没有创build位置独立代码（PIC）。 我们认为这是一个可能包含在静态库或可执行文件中的对象。 也就是说，当我们将一个可执行文件链接到.o文件时， .o文件中的代码就被插入到可执行文件中了 – 它在编译时绑定，而不是在运行时绑定。 这意味着可执行文件可以被重新分发，而不包含.o文件。 注意： .o文件被认为是非PIC的惯例。 我们通常使用.lo扩展名来命名PIC目标文件。
文件types.a
.a文件types是“ 存档 ”库。 它包含一个或多个.o文件，通常用于创build静态可执行文件。
我们使用ar命令来操作归档库。 下面的示例（1）从.o文件创build归档库，然后（2）列出其中的内容。
创build库
$ ls *.o ao bo co <=== 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 ao bo co
文件types.lo
.lo是一个惯例，通常用于位置无关的对象文件。 在当前目录中， libtool compile命令同时创build一个.lo文件和一个.o文件，一个是PIC代码，另一个是没有PIC代码的文件。 看到下面的输出：
$ libtool compile gcc -c ac libtool: compile: gcc -c ac -fPIC -DPIC -o .libs/ao <== PIC code libtool: compile: gcc -c ac -o ao >/dev/null 2>&1 <== Not-PIC code $ ls a.lo ao a.lo ao <=== a.lo contains the PIC code.
还要注意.libs子目录是在其中创build的。 这个文件是PIC代码，尽pipe名字。 Libtool将这个文件移动到当前目录，并将扩展名改为.lo 。
您可以随时手动创build.lo文件，只需在编译时使用PIC选项（g）gcc即可。 将生成的.o文件移至.lo扩展名。
文件types.so
按照惯例，这意味着一个“共享对象”库文件。 我们把PIC目标文件放到共享库中。 在与.o和.a文件的合同中，当我们与.so文件链接时，代码不包含在生成的编译文件中。 那就是我们使用运行时绑定（如.lo的情况）。 运行时绑定有多种forms，但我们不会在这里进行讨论。
.lo文件是一个库对象，可以内置到共享库中， .o文件是一个标准的对象文件。 更多信息： 如何安装和使用libtool共享库（.lo文件）？
