C/C++: What is the difference between a statically-linked library and an object file?

Question

I understand that code included in an executable at compile-time can come from object files (.o files) and statically-linked libraries (.lib/.a files). What is fundamentally and conceptually the difference between these two? Why is there a different concept between "object code" and a "statically-linked library"? What are the advantages and disadvantages to each, and why use one as opposed to the other? Can statically-linked library(ies) be made from object file(s), and vise-versa, can object file(s) be made from statically-linked library(ies)?

Unread

Answer 1

Object files are compiled but unlinked code. Libraries contain object files. Thus your question becomes, "Why use statically-linked libs if I can just use object files?" Here's why.

Unlike a collection of objects, each of which have their own symbol tables, a library has a single, unified symbol table, created when ar is called by the library developer using the s switch. s calls ranlib to create a unified symbol table for all objects in that archive.

Running ranlib in shell shows in the first line of help text:

Generate an index to speed access to archives.

And from the generic ranlib docs:

An archive with such an index speeds up linking to the library and allows routines in the library to call each other without regard to their placement in the archive. T

See also the FreeBSD ranlib docs - different wording, same idea: Speed of linkage.

Lauryn

Answer 2

A library is simply a file containing many object files, which can be searched to resolve symbols.

So typically, when you link objects together, you get all the objects in one executable (though some optimising linkers can throw out unused ones).

When you give a library to the linker, it examines each of the object files within it and brings in those that are needed to satisfy unresolved symbols (and will probably continue to bring them in until either all symbols are resolved or no more can be).

It's just a way of efficiently packaging up a lot of objects into a single file so that the linker can do more of your work - you don't have to worry about which objects you need.

If you think of the C library, you may have a printf.o, puts.o, fopen.o as a result of keeping your source well separated. You don't want the user to have to explicitly list every single object file they want so you package the whole lot up into libc.a and tell them they just need to link with that single file.

---

The statically-linked bit is irrelevant here, it just decides that the objects should go into the executable at link time rather than being dynamically loaded at run time. It's explained here.

Tedmann

So why is there any difference in efficiency or amount of work the user has to do when using a library file as opposed to one or more object files? Can't the linker just always optimize? And if statically-linked libraries are a collection of object files, then does it load each object subfile all-or-none, or does it take only those symbols that get used? Do you have an example of how material differences would occur by creating an executable from the same code based on whether that code comes from a statically-linked library vs. object file(s)? – Unread

@user553702, do you want to have to list eighty-five different object files, some of which aren't even needed, or would you rather just list libc.a and let the linker work it out? Maybe I'm inherently lazy but that's not always a bad thing :-) As to how the linker works, it could throw away ones that satisfy no symbols even if you explicitly list them. Most don't though ISTR Visual Studio was smart like that. – Tedmann

Most linkers will extract only the object files they need from a library (and all of each object file they decide they need) for simplicity. – Tedmann