概述
C和C++編譯器是集成的,編譯一般分爲四個步驟:
- 預處理(preprocessing) ----------------- cpp/ gcc -E
- 編譯(compilation) ------------------ cc1 / gcc -S
- 彙編(assembly) -------------------- as
- 連接(linking) --------------------- ld
gcc
認爲預處理的文件是(.i)是C文件,並且設定C形式的連接;
g++
認爲預處理的文件是(.i)是C++文件,並且設定C++形式的連接;
源文件後綴名的一些含義和後續的操作:
- .c C源程序 預處理,編譯,彙編
- .C C++源程序 預處理,編譯,彙編
- .cc C++源程序
- .cxx C++源程序 預處理,編譯,彙編
- .m Objective-C源程序 預處理,編譯,彙編
- .i 預處理後的C文件 編譯,彙編
- .ii 預處理後的C++文件 編譯,彙編
- .s 彙編語言源程序 彙編
- .S 彙編語言源程序 預處理,彙編
- .h 預處理器文件 通常不出現在命令行上
其他後綴名的文件被傳遞給連接器(linker).通常包括:
.o 目標文件(Object file)
.a 歸檔庫文件(Archive file)
轉載請註明出處: http://blog.csdn.net/elfprincexu
二、具體介紹一下GCC編譯步驟
首先,有以下hello.c源代碼
#include<stdio.h>
int main()
{
printf("Hello! This is our embedded world!\n");
return 0;
}
(1)預處理階段
在該階段,編譯器將上述代碼中的stdio.h編譯進來,並且用戶可以使用Gcc的選項”-E”進行查看,該選項的作用是讓Gcc在預處理結束後停止編譯過程。預處理階段主要處理#include和#define,它把#include包含進來的.h 文件插入到#include所在的位置,把源程序中使用到的用#define定義的宏用實際的字符串代替,我們可以用-E選項要求gcc只進行預處理而不進行後面的三個階段,
注意 : Gcc指令的一般格式爲:Gcc [選項] 要編譯的文件 [選項] [目標文件]
其中,目標文件可缺省,Gcc默認生成可執行的文件,命爲:編譯文件.out
[root@localhost Gcc]# Gcc –E hello.c –o hello.i
在此處,選項"-o"是指目標文件,".i"文件爲已經過預處理的C原始程序。以下列出了hello.i文件的部分內容:
typedef int (*__gconv_trans_fct) (struct __gconv_step *,
struct __gconv_step_data *, void *,
__const unsigned char *,
__const unsigned char **,
__const unsigned char *, unsigned char **,
size_t *);
…
# 2 "hello.c" 2
int main()
{
printf("Hello! This is our embedded world!\n");
return 0;
}
由此可見,Gcc確實進行了預處理,它把”stdio.h”的內容插入到hello.i文件中。
(2)編譯階段
接下來進行的是編譯階段,在這個階段中,Gcc首先要檢查代碼的規範性、是否有語法錯誤等,以確定代碼的實際要做的工作,在檢查無誤後,Gcc把代碼翻譯成彙編語言。用戶可以使用”-S”選項來進行查看,該選項只進行編譯而不進行彙編,生成彙編代碼。
上面這兩步的輸出文件都是文本文件,我們可以用諸如cat的文本處理等命令閱讀這些輸出文件。
[root@localhost Gcc]# Gcc –S hello.i –o hello.s
以下列出了hello.s的內容,可見Gcc已經將其轉化爲彙編了,感興趣的讀者可以分析一下這一行簡單的C語言小程序是如何用匯編代碼實現的。
.file "hello.c"
.section .rodata
.align 4
.LC0:
.string "Hello! This is our embedded world!"
.text
.globl main
.type main, @function
main:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
movl $0, %eax
addl $15, %eax
addl $15, %eax
shrl $4, %eax
sall $4, %eax
subl %eax, %esp
subl $12, %esp
pushl $.LC0
call puts
addl $16, %esp
movl $0, %eax
leave
ret
.size main, .-main
.ident "GCC: (GNU) 4.0.0 20050519 (Red Hat 4.0.0-8)"
.section .note.GNU-stack,"",@progbits
(3)彙編階段
彙編階段是把編譯階段生成的”.s”文件轉成目標文件,讀者在此可使用選項”-c”就可看到彙編代碼已轉化爲”.o”的二進制目標代碼了。如下所示:
[root@localhost Gcc]# Gcc –c hello.s –o hello.o
(4)鏈接階段
在成功編譯之後,就進入了鏈接階段。在這裏涉及到一個重要的概念:函數庫。
讀者可以重新查看這個小程序,在這個程序中並沒有定義”printf”的函數實現,且在預編譯中包含進的”stdio.h”中也只有該函數的聲明,而沒有定義函數的實現,那麼,是在哪裏實現”printf”函數的呢?最後的答案是:系統把這些函數實現都被做到名爲libc.so.6的庫文件中去了,在沒有特別指定時,Gcc會到系統默認的搜索路徑”/usr/lib”下進行查找,也就是鏈接到libc.so.6庫函數中去,這樣就能實現函數”printf”了,而這也就是鏈接的作用。
函數庫一般分爲靜態庫和動態庫兩種。
- 靜態庫是指編譯鏈接時,把庫文件的代碼全部加入到可執行文件中,因此生成的文件比較大,但在運行時也就不再需要庫文件了。其後綴名一般爲”.a”。
- 動態庫與之相反,在編譯鏈接時並沒有把庫文件的代碼加入到可執行文件中,而是在程序執行時由運行時鏈接文件加載庫,這樣可以節省系統的開銷。動態庫一般後綴名爲”.so”,如前面所述的libc.so.6就是動態庫。Gcc在編譯時默認使用動態庫。
說下生成靜態庫的方法:
ar cr libxxx.a file1.o file2.o
就是把file1.o和file2.o打包生成libxxx.a靜態庫
使用的時候
gcc test.c -L/path -lxxx -o test
動態庫的話:
gcc -fPIC -shared file1.c -o libxxx.so
也可以分成兩部來寫:
gcc -fPIC file1.c -c //這一步生成file1.o
gcc -shared file1.o -o libtest.so
靜態庫鏈接時搜索路徑順序:
- 1. ld會去找GCC命令中的參數-L
- 2. 再找gcc的環境變量LIBRARY_PATH
- 3. 再找內定目錄 /lib /usr/lib /usr/local/lib 這是當初compile gcc時寫在程序內的
動態鏈接時、執行時搜索路徑順序:
- 1. 編譯目標代碼時指定的動態庫搜索路徑
- 2. 環境變量LD_LIBRARY_PATH指定的動態庫搜索路徑
- 3. 配置文件/etc/ld.so.conf中指定的動態庫搜索路徑
- 4. 默認的動態庫搜索路徑/lib
- 5. 默認的動態庫搜索路徑/usr/lib
有關環境變量:
- LIBRARY_PATH環境變量:指定程序靜態鏈接庫文件搜索路徑
- LD_LIBRARY_PATH環境變量:指定程序動態鏈接庫文件搜索路徑
完成了鏈接之後,Gcc就可以生成可執行文件,如下所示。
[root@localhost Gcc]# Gcc hello.o –o hello
運行該可執行文件,出現正確的結果如下。
[root@localhost Gcc]# ./hello
Hello! This is our embedded world!