gcc/g++編譯（生動形象，從最容易入手的hello world解釋了庫的概念）
1. gcc/g++在執行編譯工作的時候，總共需要4步
(1).預處理,生成.i的文件[預處理器cpp]
(2).將預處理後的文件不轉換成匯編語言,生成文件.s[編譯器egcs]
(3).有匯編變為目標代碼(機器代碼)生成.o的文件[匯編器as]
(4).連接目標代碼,生成可執行程序[鏈接器ld]
[參數詳解]
-x language filename
設定文件所使用的語言,使後綴名無效,對以後的多個有效.也就是根據約定C語言的後綴名稱是.c的，而C++的後綴名是.C或者.cpp,如果你很個性，決定你的C代碼文件的後綴名是.pig 哈哈，那你就要用這參數,這個參數對他後面的文件名都起作用，除非到了下一個參數的使用。可以使用的參數嗎有下面的這些 :
`assembler‘, and `assembler-with-cpp‘.
看到英文，應該可以理解的。例子用法: gcc -x c hello.pig
-x none filename
關掉上一個選項，也就是讓gcc根據文件名後綴，自動識別文件類型. 例子用法: gcc -x c hello.pig -x none hello2.c
-c
只激活預處理,編譯,和匯編,也就是他只把程序做成obj文件.例子用法: gcc -c hello.c (他將生成.o的obj文件)
-S
只激活預處理和編譯，就是指把文件編譯成為匯編代碼。例子用法: gcc -S hello.c (他將生成.s的匯編代碼，你可以用文本編輯器察看 )
-E
只激活預處理,這個不生成文件,你需要把它重定向到一個輸出文件裏面.例子用法: gcc -E hello.c > pianoapan.txt
gcc -E hello.c | more (慢慢看吧,一個hello word 也要與處理成800行的代碼 )
-o
制定目標名稱,缺省的時候,gcc 編譯出來的文件是a.out,很難聽,如果你和我有同感，改掉它,哈哈 .例子用法 :
gcc -o hello.exe hello.c (哦,windows用習慣了)
-pipe
使用管道代替編譯中臨時文件,在使用非gnu匯編工具的時候,可能有些問題. 例子用法 :gcc -pipe -o hello.exe hello.c
-ansi
關閉gnu c中與ansi c不兼容的特性,激活ansi c的專有特性(包括禁止一些asm inline typeof關鍵字,以及UNIX,vax等預處理宏.)
-fno-asm
此選項實現ansi選項的功能的一部分，它禁止將asm,inline和typeof用作關鍵字。
-fno-strict-prototype
只對g++起作用,使用這個選項,g++將對不帶參數的函數,都認為是沒有顯式的對參數的個數和類型說明,而不是沒有參數.
而gcc無論是否使用這個參數,都將對沒有帶參數的函數,認為城沒有顯式說明的類型
-fthis-is-varialble
就是向傳統c++看齊,可以使用this當一般變量使用.
-fcond-mismatch
允許條件表達式的第二和第三參數類型不匹配,表達式的值將為void類型
-funsigned-char
-fno-signed-char
-fsigned-char
-fno-unsigned-char
這四個參數是對char類型進行設置,決定將char類型設置成unsigned char(前兩個參數)或者 signed char(後兩個參數)
-include file
包含某個代碼,簡單來說,就是便以某個文件,需要另一個文件的時候,就可以用它設定,功能就相當於在代碼中使用#include<filename>
例子用法: gcc hello.c -include /root/pianopan.h
-imacros file
將file文件的宏,擴展到gcc/g++的輸入文件,宏定義本身並不出現在輸入文件中-Dmacro .相當於C語言中的#define macro
-Dmacro=defn
相當於C語言中的#define macro=defn
-Umacro
相當於C語言中的#undef macro
-undef
取消對任何非標準宏的定義
-Idir
在你是用#include"file"的時候,gcc/g++會先在當前目錄查找你所制定的頭文件,如果沒有找到,他回到缺省的頭文件目錄找,如果使用-I制定了目錄,他回先在你所制定的目錄查找,然後再按常規的順序去找. 對於#include<file>,gcc/g++會到-I制定的目錄查找,查找不到,然後將到系統的缺省的頭文件目錄查找 .
-I-
就是取消前一個參數的功能,所以一般在-Idir之後使用
-idirafter dir
在-I的目錄裏面查找失敗,講到這個目錄裏面查找.
-iprefix prefix
-iwithprefix dir
一般一起使用,當-I的目錄查找失敗,會到prefix+dir下查找
-nostdinc
使編譯器不再系統缺省的頭文件目錄裏面找頭文件,一般和-I聯合使用,明確限定頭文件的位置
-nostdin C++
規定不在g++指定的標準路經中搜索,但仍在其他路徑中搜索,.此選項在創建libg++庫使用
-C
在預處理的時候,不刪除註釋信息,一般和-E使用,有時候分析程序，用這個很方便的.
-M
生成文件關聯的信息。包含目標文件所依賴的所有源代碼.你可以用gcc -M hello.c來測試一下，很簡單。
-MM
和上面的那個一樣，但是它將忽略由#include<file>造成的依賴關系。
-MD
和-M相同，但是輸出將導入到.d的文件裏面
-MMD
和-MM相同，但是輸出將導入到.d的文件裏面
-Wa,option
此選項傳遞option給匯編程序;如果option中間有逗號,就將option分成多個選項,然後傳遞給會匯編程序
-Wl.option
此選項傳遞option給連接程序;如果option中間有逗號,就將option分成多個選項,然後傳遞給會連接程序.
-llibrary
制定編譯的時候使用的庫.例子用法 : gcc -lcurses hello.c (使用ncurses庫編譯程序 )
-Ldir
制定編譯的時候，搜索庫的路徑。比如你自己的庫，可以用它制定目錄，不然編譯器將只在標準庫的目錄找。這個dir就是目錄的名稱。
-O0
-O1
-O2
-O3
編譯器的優化選項的4個級別，-O0表示沒有優化,-O1為缺省值，-O3優化級別最高
-g
只是編譯器，在編譯的時候，產生條是信息。
-gstabs
此選項以stabs格式聲稱調試信息,但是不包括gdb調試信息.
-gstabs+
此選項以stabs格式聲稱調試信息,並且包含僅供gdb使用的額外調試信息.
-ggdb
此選項將盡可能的生成gdb的可以使用的調試信息.
-static
此選項將禁止使用動態庫，所以，編譯出來的東西，一般都很大，也不需要什麽動態連接庫，就可以運行.
-share
此選項將盡量使用動態庫，所以生成文件比較小，但是需要系統由動態庫.
-traditional
試圖讓編譯器支持傳統的C語言特性
2. 源文件為main.c, x.c, y.c, z.c,頭文件為x.h,y.h,z.h, 如何編譯成.so動態庫？
# 聲稱動代連接庫，假設名稱為libtest.so
gcc x.c y.c z.c -fPIC -shared -o libtest.so
# 將main.c和動態連接庫進行連接生成可執行文件
gcc main.c -L. -ltest -o main
# 輸出LD_LIBRARY_PATH環境變量，一邊動態庫裝載器能夠找到需要的動態庫
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.
# 測試是否動態連接，如果列出libtest.so，那麽應該是連接正常了
ldd main
說明：
(1) -fPIC：表示編譯為位置獨立的代碼，不用此選項的話編譯後的代碼是位置相關的所以動態載入時是通過代碼拷貝的方式來滿足不同進程的需要，而不能達到真正代碼段共享的目的。
(2) -L.：表示要連接的庫在當前目錄中
(3) -ltest：編譯器查找動態連接庫時有隱含的命名規則，即在給出的名字前面加上lib，後面加上.so來確定庫的名稱
(4) LD_LIBRARY_PATH：這個環境變量指示動態連接器可以裝載動態庫的路徑。
當然如果有root權限的話，可以修改/etc/ld.so.conf文件，然後調用/sbin/ldconfig來達到同樣的目的，不過如果沒有root權限，那麽只能采用輸出LD_LIBRARY_PATH的方法了。
3. Linux下如何用GCC編譯動態庫
本文主要解決以下幾個問題
1) 為什麽要使用庫？
2) 庫的分類
3) 創建自己的庫
或許大家對自己初學 Linux時的情形仍記憶尤新吧。如果沒有一個能較好的解決依賴關系的包管理器，在Linux下安裝軟件將是一件及其痛苦的工作。你裝a包時，可能會提示你要先裝b包，當你費盡心力找到b包時，可能又會提示你要先安裝c包。我就曾被這樣的事搞的焦頭爛額，至今一提起rpm仍心有余悸，頭皮發麻。說是一朝被蛇咬，十年怕井繩怕也不為過。
Linux下之所以有這許多的依賴關系，其中一個開發原則真是功不可沒。這個原則就是：盡量不重復做別人已經做過的事。換句話說就是盡量充分利用別人的勞動成果。
這就涉及到如何有效的進行代碼復用。
(1) 為什麽要使用庫？
關於代碼復用的途徑，一般有兩種。這是最沒有技術含量的一種方案。如果代碼小，則工作量還可以忍受，如果代碼很龐大，則此法不可取。即便有人原意這樣做，但誰又能保證所有的代碼都可得到呢？而庫的出現很好的解決了這個問題。庫，是一種封裝機制，簡單說把所有的源代碼編譯成目標代碼後打成的包。那麽用戶怎麽能知道這個庫提供什麽樣的接口呢？難道要用nm等工具逐個掃描？不用擔心，庫的開發者早以把一切都做好了。除了包含目標代碼的庫外，www.Linuxidc.com一般還會提供一系列的頭文件，頭文件中就包含了庫的接口。為了讓方便用戶，再加上一個使用說明就差不多完美了。
(2) 庫的分類
(2.1) 庫的分類
根據鏈接時期的不同，庫又有靜態庫和動態庫之分。靜態庫是在鏈接階段被鏈接的（好像是廢話，但事實就是這樣），所以生成的可執行文件就不受庫的影響了，即使庫被刪除了，程序依然可以成功運行。有別於靜態庫，動態庫的鏈接是在程序執行的時候被鏈接的。所以，即使程序編譯完，庫仍須保留在系統上，以供程序運行時調用。（TODO：鏈接動態庫時鏈接階段到底做了什麽）
(2.2) 靜態庫和動態庫的比較
鏈接靜態庫其實從某種意義上來說也是一種粘貼復制，只不過它操作的對象是目標代碼而不是源碼而已。因為靜態庫被鏈接後庫就直接嵌入可執行文件中了，這樣就帶來了兩個問題。首先就是系統空間被浪費了。這是顯而易見的，想象一下，如果多個程序鏈接了同一個庫，則每一個生成的可執行文件就都會有一個庫的副本，必然會浪費系統空間。再者，人非聖賢，即使是精心調試的庫，也難免會有錯。一旦發現了庫中有bug，挽救起來就比較麻煩了。必須一一把鏈接該庫的程序找出來，然後重新編譯。而動態庫的出現正彌補了靜態庫的以上弊端。因為動態庫是在程序運行時被鏈接的，所以磁盤上只須保留一份副本，因此節約了磁盤空間。如果發現了bug或要升級也很簡單，只要用新的庫把原來的替換掉就行了。那麽，是不是靜態庫就一無是處了呢？答曰：非也非也。不是有句話麽：存在即是合理。靜態庫既然沒有湮沒在滔滔的歷史長河中，就必然有它的用武之地。想象一下這樣的情況：如果你用libpcap庫編了一個程序，要給被人運行，而他的系統上沒有裝pcap庫，該怎麽解決呢？最簡單的辦法就是編譯該程序時把所有要鏈接的庫都鏈接它們的靜態庫，這樣，就可以在別人的系統上直接運行該程序了。
所謂有得必有失，正因為動態庫在程序運行時被鏈接，故程序的運行速度和鏈接靜態庫的版本相比必然會打折扣。然而瑕不掩瑜，動態庫的不足相對於它帶來的好處在現今硬件下簡直是微不足道的，所以鏈接程序在鏈接時一般是優先鏈接動態庫的，除非用-static參數指定鏈接靜態庫。
(2.3) 如何判斷一個程序有沒有鏈接動態庫? 答案是用file實用程序。
file程序是用來判斷文件類型的，在file命令下，所有文件都會原形畢露的。順便說一個技巧。有時在 windows下用瀏覽器下載tar.gz或tar.bz2文件，後綴名會變成奇怪的tar.tar，到Linux有些新手就不知怎麽解壓了。但 Linux下的文件類型並不受文件後綴名的影響，所以我們可以先用命令file xxx.tar.tar看一下文件類型，然後用tar加適當的參數解壓。
另外，還可以借助程序ldd實用程序來判斷。ldd是用來打印目標程序（由命令行參數指定）所鏈接的所有動態庫的信息的，如果目標程序沒有鏈接動態庫，則打印“not a dynamic executable”，ldd的用法請參考manpage。
(3) 創建自己的庫
(3.1) 創建動態庫
創建文件hello.c，內容如下：
#include
void hello(void)
{
printf("Hello World\n");
}
用命令gcc -shared hello.c -o libhello.so編譯為動態庫。可以看到，當前目錄下多了一個文件libhello.so。
[[email protected] test]$ file libhello.so
libhello.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped
看到了吧，文件類型是shared object了。再編輯一個測試文件test.c，內容如下：
int main()
{
hello();
return 0;
}
這下可以編譯了：）
[[email protected] test]$ gcc test.c
/tmp/ccm7w6Mn.o: In function `main‘:
test.c:(.text+0x1d): undefined reference to `hello‘
collect2: ld returned 1 exit status
鏈接時gcc找不到hello函數，編譯失敗:(。原因是hello在我們自己創建的庫中，如果gcc能找到那才教見鬼呢！ok，再接再厲。
[[email protected] test]$ gcc test.c -lhello
/usr/lib/gcc/i686-pc-Linux-gnu/4.0.0/http://www.cnblogs.com/http://www.cnblogs.com/i686-pc-Linux-gnu/bin/ld: cannot find -lhello
collect2: ld returned 1 exit status
[[email protected] test]$ gcc test.c -lhello -L.
[[email protected] test]$
第一次編譯直接編譯，gcc默認會鏈接標準c庫，但符號名hello解析不出來，故連接階段通不過了。現在用gcc test.c -lhello -L.已經編譯成功了，默認輸出為a.out。現在來試著運行一下：
[[email protected] test]$ ./a.out
./a.out: error while loading shared libraries: libhello.so: cannot open shared object file: No such file or directory
咦，怎麽回事？原來雖然鏈接時鏈接器（dynamic linker）找到了動態庫libhello.so，但動態加載器(dynamic loader， 一般是/lib/ld-Linux.so.2)卻沒找到。再來看看ldd的輸出：
[[email protected] test]$ ldd a.out
Linux-gate.so.1 => (0xffffe000)
libhello.so => not found
libc.so.6 => /lib/libc.so.6 (0x40034000)
/lib/ld-Linux.so.2 (0x40000000)
果然如此，看到沒有，libhello.so => not found。Linux為我們提供了兩種解決方法：
1).可以把當前路徑加入 /etc/ld.so.conf中然後運行ldconfig，或者以當前路徑為參數運行ldconfig（要有root權限才行）。
2).把當前路徑加入環境變量LD_LIBRARY_PATH中
當然，如果你覺得不會引起混亂的話，可以直接把該庫拷入/lib,/usr/lib/等位置（無可避免，這樣做也要有權限），這樣鏈接器和加載器就都可以準確的找到該庫了。我們采用第二種方法：
[[email protected] test]$ export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
[[email protected] test]$ ldd a.out
Linux-gate.so.1 => (0xffffe000)
libhello.so => ./libhello.so (0x4001f000)
libc.so.6 => /lib/libc.so.6 (0x40036000)
/lib/ld-Linux.so.2 (0x40000000)
哈哈，這下ld-Linux.so.2就可以找到libhello.so這個庫了。現在可以直接運行了：
[[email protected] test]$ ./a.out
Hello World
(3.2) 創建靜態庫
仍使用剛才的hello.c和test.c。第一步，生成目標文件。
[[email protected] test]$ gcc -c hello.c
[[email protected] test]$ ls hello.o -l
-rw-r--r-- 1 leo users 840 5月 6 12:48 hello.o
第二步,把目標文件歸檔。
[[email protected] test]$ ar r libhello.a hello.o
ar: creating libhello.a
OK,libhello.a就是我們所創建的靜態庫了，簡單吧:)
[[email protected] test]$ file libhello.a
libhello.a: current ar archive
下面一行命令就是教你如何在程序中鏈接靜態庫的：
[[email protected] test]$ gcc test.c -lhello -L. -static -o hello.static
我們來用file命令比較一下用動態庫和靜態庫鏈接的程序的區別：
[[email protected] test]$ gcc test.c -lhello -L. -o hello.dynamic
正如前面所說，鏈接器默認會鏈接動態庫（這裏是libhello.so），所以只要把上個命令中的 -static參數去掉就可以了。用file實用程序驗證一下是否按我們的要求生成了可執行文件：
[[email protected] test]$ file hello.static hello.dynamic
hello.static: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.6, statically linked, not stripped
hello.dynamic: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.6, dynamically linked (uses shared libs), not stripped
不妨順便練習一下ldd的用法：
[[email protected] test]$ ldd hello.static hello.dynamic
hello.static:
not a dynamic executable
hello.dynamic:
Linux-gate.so.1 => (0xffffe000)
libhello.so => ./libhello.so (0x4001f000)
libc.so.6 => /lib/libc.so.6 (0x40034000)
/lib/ld-Linux.so.2 (0x40000000)
OK，看來沒有問題，那就比較一下大小先：
[[email protected] test]$ ls -l hello.[ds]*
-rwxr-xr-x 1 leo users 5911 5月 6 12:54 hello.dynamic
-rwxr-xr-x 1 leo users 628182 5月 6 12:54 hello.static
看到區別了吧，鏈接靜態庫的目標程序和鏈接動態庫的程序比起來簡直就是一個龐然大物！這麽小的程序，很難看出執行時間的差別，不過為了完整起見，還是看一下time的輸出吧：
[[email protected] test]$ time ./hello.static
Hello World
real 0m0.001s
user 0m0.000s
sys 0m0.001s
[[email protected] test]$ time ./hello.dynamic
Hello World
real 0m0.001s
user 0m0.000s
sys 0m0.001s
如果程序比較大的話，應該效果會很明顯的。
http://www.cnblogs.com/yc_sunniwell/archive/2010/07/22/1782678.html
gcc/g++編譯（生動形象，從最容易入手的hello world解釋了庫的概念）