Reputation: 4452
What is the difference between .a
.o
and .lo
file in C?
Upvotes: 93
Views: 59276
Reputation: 2331
Note:
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).
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.
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
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.
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.
Upvotes: 112
Reputation: 5766
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
Upvotes: 47
Reputation: 20658
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)?
Upvotes: 3