C源程式需要經過預處理、編譯、彙編幾個階段，得到各自原始檔對應的可重定位目標檔案，可重定位目標檔案就是各個原始檔的二進位制機器程式碼，一般是.o格式。比如：util1.c、util2.c及main.c三個C原始檔，經過前處理器、編譯器、彙編器的處理，就可以得到各自的目標檔案util1.o，util2.o以及main.o。可重定位目標檔案中的地址是從0開始的，需要連結器將若干個可重定位目標檔案透過符號解析、重定位等工作，連結成為一個可執行的二進位制目標檔案。在Linux下，可以使用gcc -c 對原始檔進行預處理、編譯、彙編，得到目標檔案：
可以看到原始檔util1.c及util2.c被編譯成為了對應的目標檔案util1.o及util2.o。在給定的例子中，util1.c和util2.c實際上分別定義了兩個函式add和mult，返回兩個整數的加法和乘法結果(這麼做有點兒蠢，這裡只是作為一個例子，講清楚後面靜態庫的概念)。兩個函式的定義如下：
//util1.c int add(int a,int b) { return a + b; } //util2.c int mult(int a,int b) { return a * b; }
util.h中包含了對這兩個函式的宣告。 main.c使用其中的add函式：
#include <stdio.h> #include "util.h" int main() { int a = 5; int b = 10; int c = add(a,b); printf("%d\n",c); return 0; }
實際上，所有的編譯系統都提供一種機制，將所有相關的目標模組(即目標檔案)打包成為一個單獨的檔案，稱為靜態庫。在Linux中，靜態庫以一種被稱為存檔(archive)的檔案格式存放在磁碟中。存檔檔案由字尾.a標識，.a格式的存檔檔案是一組連線起來的可重定位目標檔案的集合，有一個頭部用來描述每個成員目標檔案的大小和位置。C標準定義了許多靜態庫，如標準IO操作scanf,printf，字串操作strcpy等，它們在libc.a庫中；一些浮點數學函式如sin,cos等，它們在libm.a庫中。
當然，靜態庫是目標檔案的集合，我們也可以將自己定義的函式編譯成目的碼，加入靜態庫中。為了為若干目標檔案建立靜態庫，可以使用ar rcs:
ar rcs 後面緊跟的libutil.a是建立的靜態庫的名字，通常以lib三個字母開頭，後面的util可以自己指定，靜態庫以.a為字尾。util1.o 及 util2.o 是我們要加入靜態庫的兩個目標檔案。這樣，就建立了一個靜態庫檔案libutil.a。可以使用ar t來檢視靜態庫檔案中包含的目標檔案：
接下來，我們在main函式中使用這個庫。要在main中使用libutil.a庫，需要連結透過編譯main.c得到的目標檔案main.o和libutil.a:
可以看到，gcc將main.c對應的目標檔案與庫libutil.a連結起來，得到了可執行檔案main。我們執行可執行檔案main，得到期望的結果：
注意，main函式中include了標頭檔案util.h，在util.h中對libutil.a中的函式進行了宣告。
那麼，重點來了，為什麼需要引入靜態庫這種東西呢？將C標準提供的所有庫都放在一個可重定位目標模組中不行嗎？
事實上是可以的，不過，這種設計有一個很大的缺點是系統中的每個可執行檔案都要包含這個整個的大的目標模組的完全副本，這樣做很浪費儲存空間。比如，C標準的libc.a大約5MB，現在有一臺機器裝載了15個用到了C標準庫的可執行檔案，那麼這15個可執行檔案裡每一個實際上都經過連結器的連結，嵌入了libc.a庫中的5MB目的碼，而實際上它們可能用到5MB目的碼裡的很小一部分(比如，某個目標檔案可能只引用了標準庫中的strcpy函式)，這樣，造成了嚴重的儲存空間浪費。而靜態庫實際上提供了這樣一種功能：相關的函式可以被編譯為獨立的目標模組，然後封裝成一個單獨的靜態庫檔案，當連結器構造一個可執行檔案時，它只“提取”靜態庫裡被應用程式引用的目標模組(換句話說，對於程式中用不到的，連結器不會將它複製到可執行檔案中去)，比如例子中main.c只用到了add函式，連結器就只會將庫libutil.a中的multi1模組複製到可執行檔案，而不會複製multi2模組。
還有一種方法，就是把每個函式建立獨立的可重定位目標檔案。而這種方法對於應用程式設計師來說是及其不友好的，因為這種方法要求應用程式設計師顯示地連結需要的目標模組到可執行檔案中，這是一個容易出錯且耗時的過程。
總結來說，靜態庫提供了將每一個目標模組獨立地打包的功能，並且可以由連結器自動地提取被程式引用的目標模組，這減少了可執行檔案在磁碟和記憶體中的大小，並且大大降低了程式設計師連結各個目標檔案的壓力。