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.

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