g++是 linux下c++的編譯器,在執行編譯工作的時候，總共需要4步
1.預處理,生成.i的檔案
2.將預處理後的檔案不轉換成組合語言,生成檔案.s
3.有彙編變為目標**(機器**)生成.o的檔案
4.連線目標**,生成可執行程式
g++ 編譯c++經常使用的引數：
-c
只編譯，不連線。例如： g++ -c helloworld.cpp-o只生成helloworld.o不連線
指定輸出檔名。例如：g++ -c helloworld.cpp -o abc.o-i預設是生成helloworld.o，用-o abc.o以後，就生成的是abc.o
附加乙個包函標頭檔案的路徑。例如：g++ helloworld.cpp -i"/usr/helloworld/include"-l
小的l， 附乙個庫，例如要使用libabc.so 就g++ helloworld.cpp -labc-l
新增乙個庫的路徑，例如 g++ hello.cpp -l"/usr/hello/lib" -labc-shared
生成動態庫檔案，例如： g++ -shared hellp.cpp -o libhello.so
-d，-u
-d將巨集定義傳遞給程式，-u取消程式中的巨集定義，
過巨集定義（比如_debug_）對一些功能或者日誌進行開關控制，比如將中間狀態儲存到檔案中，供分析用等。例如：g++ -g -d_test -o test test.cpp 這樣，就不用在cpp中 #define _test了
呼叫動態庫的時候有幾個問題會經常碰到，有時，明明已經將庫的標頭檔案所在目錄通過include進來了，庫所在檔案通過 「-l」引數引導，並指定了「-l」的庫名，但通過ldd命令察看時，就是死活找不到你指定鏈結的so檔案。其實編譯鏈結上了共享庫不代表執行時可以找到。所以「-l」什麼的對執行沒有用，你需要指明共享庫的路徑。方法有三個：
a.修改 ld_library_path，指明共享庫的路徑。ld_library_path：這個環境變數指示動態聯結器可以裝載動態庫的路徑。在終端下使用如下命令：
[root@localhost sharelib]# export ld_library_path = .
[root@localhost sharelib]# export ld_library_path = your lib dir export
b.通過/etc/ld.so.conf檔案來指定動態庫的目錄。然後執行ldconfig命令更新搜尋共享庫的路徑。通常這個做法就可以解決庫無法鏈結的問題並且一勞永逸。 c.或者把庫檔案拷貝到/lib下，然後ldconfig就ok了。這個方法有的取巧，且破壞原庫檔案的純潔性，不應是首選方法。
修改/etc/ld.so.conf檔案，然後呼叫 /sbin/ldconfig需要有root許可權，如果沒有root許可權，那麼只能採用輸出ld_library_path的方法了。
linux下檔案的型別是不依賴於其字尾名的，但一般來講：
.o,是目標檔案,相當於windows中的.obj檔案
.so 為共享庫,是shared object,用於動態連線的,和dll差不多
.a為靜態庫,是好多個.o合在一起,用於靜態連線
.la為libtool自動生成的一些共享庫，主要記錄了一些配置資訊。
linux下c 的編譯器g 的基本使用
linux下c 的編譯器g 的基本使用 g 是 linux下c 的編譯器,在執行編譯工作的時候，總共需要4步 1.預處理,生成.i的檔案 2.將預處理後的檔案不轉換成組合語言,生成檔案.s 3.有彙編變為目標 機器 生成.o的檔案 4.連線目標 生成可執行程式 g 編譯c 經常使用的引數 c 只編譯...
Linux下gcc編譯器和g 編譯器的那些事兒
使用c c 程式設計大約有三四個年頭了。最開始涉及到微控制器 嵌入式linux等，都使用的是c語言，那時主要寫linux驅動，甚至在arm板上寫linux應用程式時需要應用物件導向的思想的時候，都是使用c語言的結構體和函式指標來實現。當然，使用的編譯器自然就是gcc了。後來，慢慢的轉向了使用c 編寫...
Linux 下的 gcc, g 編譯器
linux自帶gcc 和 g 的 gcc引數詳解 gcc and g 分別是gnu的c c 編譯器 gcc g 在執行編譯工作的時候，總共需要4步 1.預處理,生成.i的檔案 2.將預處理後的檔案不轉換成組合語言,生成檔案.s 3.有彙編變為目標 機器 生成.o的檔案 4.連線目標 生成可執行程式 ...