編譯-編譯原理C/C++ 靜態鏈接庫(.a) 與 動態鏈接庫(.so)
1.庫的分類
根據鏈接時期的不同，庫又有靜態庫和動態庫之分。
靜態庫是在鏈接階段被鏈接的（好像是廢話，但事實就是這樣），所以生成的可執行文件就不受庫的影響了，即使庫被刪除了，程序依然可以成功運行。
有別於靜態庫，動態庫的鏈接是在程序執行的時候被鏈接的。所以，即使程序編譯完，庫仍須保留在系統上，以供程序運行時調用。（TODO：鏈接動態庫時鏈接階段到底做了什麼）
2 靜態庫和動態庫的比較
鏈接靜態庫其實從某種意義上來說也是一種粘貼複製，只不過它操作的對象是目標代碼而不是源碼而已。因爲靜態庫被鏈接後庫就直接嵌入可執行文件中了，這樣就帶來了兩個問題。
首先就是系統空間被浪費了。這是顯而易見的，想象一下，如果多個程序鏈接了同一個庫，則每一個生成的可執行文件就都會有一個庫的副本，必然會浪費系統空間。
再者，人非聖賢，即使是精心調試的庫，也難免會有錯。一旦發現了庫中有bug，挽救起來就比較麻煩了。必須一一把鏈接該庫的程序找出來，然後重新編譯。
而動態庫的出現正彌補了靜態庫的以上弊端。因爲動態庫是在程序運行時被鏈接的，所以磁盤上只須保留一份副本，因此節約了磁盤空間。如果發現了bug或要升級也很簡單，只要用新的庫把原來的替換掉就行了。
那麼，是不是靜態庫就一無是處了呢？
答曰：非也非也。不是有句話麼：存在即是合理。靜態庫既然沒有湮沒在滔滔的歷史長河中，就必然有它的用武之地。想象一下這樣的情況：如果你用libpcap庫編了一個程序，要給被人運行，而他的系統上沒有裝pcap庫，該怎麼解決呢？最簡單的辦法就是編譯該程序時把所有要鏈接的庫都鏈接它們的靜態庫，這樣，就可以在別人的系統上直接運行該程序了。
所謂有得必有失，正因爲動態庫在程序運行時被鏈接，故程序的運行速度和鏈接靜態庫的版本相比必然會打折扣。然而瑕不掩瑜，動態庫的不足相對於它帶來的好處在現今硬件下簡直是微不足道的，所以鏈接程序在鏈接時一般是優先鏈接動態庫的，除非用-static參數指定鏈接靜態庫。
gcc作爲編譯工具，用在Linux操作系統中，可以編譯C、C++、Object-C、JAVA等語言。編譯過程中可以帶編譯選項，選擇編譯過程。
一、GCC編譯流程
1）預處理 Pre-Processing
2）編譯 Compiling
3）彙編 Assembling
4）鏈接 Linking
二、GCC編譯選項
1、gcc總體選項列表
1） -c ：指編譯，不鏈接，生成目標文件「.o」。
2） -S ：只編譯，不彙編，生成彙編代碼「.S」。
3） -E ：只進行預編譯/預處理，不做其他處理。
4） -o file：把輸出文件輸出到file裏。
5） -g ：在可執行程序中包含標準調試信息。
6） -v ：打印出編譯器內部編譯各過程的命令行信息和編譯器的版本。
7） -I dir ：在頭文件的搜索路徑列表中添加dir目錄
8） -L dir ：在庫文件的搜索路徑列表中添加dir目錄
9） -static ：連接靜態庫（靜態庫也可以用動態庫鏈接方式鏈接）
10） -llibrary ：連接名爲library的庫文件（顯示指定需要鏈接的動態庫文件）
2、gcc告警和出錯選項
1） -ansi ：支持符合ANSI標準的C程序
2） -pedantic ：允許發出ANSI C標準所列出的全部警告信息
3） -pedantic-error ：允許發出ANSI C標準所列出的全部錯誤信息
4） -w ：關閉所有警告
5） -Wall ：允許發出gcc提供的所有有用的報警信息
6） -werror ：把所有的告警信息轉化爲錯誤信息，並在告警發生時終止編譯過程
3、gcc優化選項
gcc可以對代碼進行優化，它通過編譯選項「-On」來控制優化代碼的生成，其中n是一個代表優化級別的整數。對於不同版本的gcc，
n的取值範圍不一致，比較典型的範圍爲0變化到2或者3。
雖然優化選項可以加速代碼的運行速度，但對於調試而言將是一個很大的挑戰。因爲代碼在經過優化之後，原先在源程序中聲明和使用
的變量很可能不再使用，控制流也可能會突然跳轉到意外的地方，循環語句也可能因爲循環展開而變得到處都有。
參考文章：
gcc編譯工具生成動態庫和靜態庫之一----介紹
C/C++ 靜態鏈接庫(.a) 與 動態鏈接庫(.so)
iOS編譯過程的原理和應用
https://blog.csdn.net/Deft_MKJing/article/details/82929014