Why create a .a file from .o for static linking?

Question

Consider this code:

one.c:

#include <stdio.h>  int one() {    printf("one!\n");    return 1; } 

two.c:

#include <stdio.h>  int two() {    printf("two!\n");    return 2; } 

prog.c

#include <stdio.h>  int one(); int two();  int main(int argc, char *argv[])  {    one();    two();     return 0; } 

I want to link these programs together. So I do this:

gcc -c -o one.o one.c gcc -c -o two.o two.c gcc -o a.out prog.c one.o two.o 

This works just fine.

Or I could create a static library:

ar rcs libone.a one.o ar rcs libtwo.a two.o gcc prog.c libone.a libtwo.a gcc -L. prog.c -lone -ltwo 

So my question is: why would I use the second version - the one where I created a ".a" files - rather than linking my ".o" files? They both seem to be statically linking, so is there an advantage or architectural difference in one vs another?

Answer 1

Typically libraries are collections of object files that can be used in multiple programs.

In your example there is no advantage, but you might have done:

ar rcs liboneandtwo.a one.o two.o 

Then linking your program becomes simpler:

gcc -L. prog.c -loneandtwo 

It's really a matter of packaging. Do you have a set of object files that naturally form a set of related functionality that can be reused in multiple programs? If so, then they can sensibly be archived into a static library, otherwise there probably isn't any advantage.

There is one important difference in the final link step. Any object files that you linked will be included in the final program. Object files that are in libraries are only included if they help resolve any undefined symbols in other object files. If they don't, they won't be linked into the final executable.