What is the difference between a static library and an archive library?

Question

In the comments of a recent answer, I equated a static library with an archive of compiled object files.

The response was that they are not the same, so what is the difference?

To clarify - gcc accepts an archive of object files as a library, as per Ar_(Unix) #Example_usage. How does this differ from other forms of static library (if any), and what benefits or negatives are there from using these different library types?

The specific claim was that compiling the source files directly instead of linking with a static library

will result in faster and better code, especially if you turn on Link Time Optimisation.

and

You can make an archive of .o files that have been compiled with -flto but those aren't really a static library

however if there are other differences, then I welcome answers addressing those.

Answer 1

A static library is just an ar archive (like zip but ancient) of object files. An object file is the source code that has been compiled to machine code, but hasn't been linked yet. You can make a static library like this (on Linux/OSX):

# Create a source file containing the single function in our library.
echo "int answer() { return 42; }" > answer.cpp
# Compile it to machine code.
c++ -c answer.cpp -o answer.o
# Compress it into an ar archive.
ar -r libanswer.a answer.o

That's it. The ar format isn't specific to static libraries at all. You can use it like Zip if you want (but nobody does because it is old and rubbish). There is also one slight improvement you can make which is to add an index to all the symbols in the library which can give a performance improvement when linking. Like this:

ar -rs libanswer.a answer.o

That's all ranlib does if you've ever wondered.

Anyway - the point about Link Time Optimisation is that it doesn't create a "real" object file, in the sense that it doesn't compile to machine code. Take a look:

$ c++ -c answer.cpp -o answer.o
$ c++ -c answer.cpp -flto -o answer_lto.o
$ file answer.o
answer.o: Mach-O 64-bit object x86_64
$ file answer_lto.o
answer_lto.o: LLVM bitcode, wrapper x86_64

answer.o is a native Mach-O object file (because I am on Mac; on Linux it will be ELF). But answer_lto.o is not! It's LLVM bitcode. That hasn't been compiled to machine code.

You can put this in an ar archive if you want:

ar -r libanswer_lto.a answer_lto.o

But this isn't a real static library, and no tools (except Clang) will be able to link with it. GCC could link with libanswer.a but not with libanswer_lto.a.

I guess you could call libanswer_lto.a a "static library" if you wanted (definitions can change etc.) but if you said "here is a static library" and gave them libanswer_lto.a most people would say "what, no it isn't".

I would call it an LLVM bitcode library or something like that.

Answer 2

They're both the same, and they're both made by ar.

An archive of object files (made by ar rc $object_files or something similar) is equivalent to other forms of a static library (of which, as far as I know, there are none).

The claim

that compiling the source files directly instead of linking with a static library will result in faster and better code

is not true. There is no overall effect of linking from a static archive vs. linking against the source/object files directly. In fact, linking object files directly may significantly increase executable size.

The claim

You can make an archive of .o files that have been compiled with -flto but those aren't really a static library

is not necessarily true. Those object files should work when linked into any program or shared library, and the difference is not obvious as to whether they are regular object files or LTO objects.