Difference between .a .o and .lo file

Question

What is the difference between .a .o and .lo file in C?

Solution 1

The '.lo' file is a library object, which may be built into a shared library, and the '.o' file is a standard object file

The .lo file is the libtool object, which Libtool uses to determine what object file may be built into a shared library

Solution 2

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.

Solution 3

The .lo file is a library object, which may be built into a shared library, and the .o file is a standard object file. More info: How to install and use libtool shared library (.lo files)?

Comments

[Raj]

Does that mean .o files CANNOT be built into a shared library?

[Raj]

Does that mean .o files CANNOT be built into a shared library?

[DumbCoder]

@Raj Kumar - stackoverflow.com/questions/2583770/…

[kusma]

The most important technical difference is that a .lo-file should contain relocatable code (-fPIC in GCC), whereas a .o-file might not.

[Fixee]

Do you really want all of your answer to be in the form of links?

[Slava]

@Raj no it does not, that naming is convenience, not requirement.

[wandadars]

Is there a book that covers the type of information that you have explained in your answer? I can only locate useful practical information like your post in forums, etc. The knowledge is fragmented and never presented as a coherent coverage of how programs are built and run.

[Łukasz Daniluk]

Nope. *.lo files are human readable, plain text files that contain name of pic object and non_pic object. PIC code is usually in .libs/a.o and and nonPIC is in a.o. So libtool creates 3 files: 2 object files (.o), one PIC and one not + .lo file which describes where the files are.

[Heinrich Hartmann]

@wandadars: Check out "Linkers and Loaders" by John R. Levine linker.iecc.com

[Mayank Sharma]

This is a much higher quality answer, and should be the accepted one.