gcc、glibc、arm-linux-gcc之間有哪些聯(lián)系？

一、GCC簡(jiǎn)介

The GNU Compiler Collection，通常簡(jiǎn)稱 GCC，是一套由 GNU 開發(fā)的編譯器集，為什么是編輯器集而不是編譯器呢？那是因?yàn)樗粌H支持 C 語(yǔ)言編譯，還支持 C++， Ada，Objective C 等許多語(yǔ)言。

另外 GCC 對(duì)硬件平臺(tái)的支持，可以所無(wú)所不在，它不僅支持 X86處理器架構(gòu), 還支持 ARM, Motorola 68000, Motorola 8800，AtmelAVR，MIPS 等處理器架構(gòu)。

二、GCC的組成結(jié)構(gòu)

GCC 內(nèi)部結(jié)構(gòu)主要由 Binutils、gcc-core、Glibc 等軟件包組成。

Binutils：它是一組開發(fā)工具，包括連接器，匯編器和其他用于目標(biāo)文件和檔案的工具。關(guān)于 Binutils 的介紹可以參考 Binutils 簡(jiǎn)單介紹。這個(gè)軟件包依賴于不同的目標(biāo)機(jī)的平臺(tái)。因?yàn)椴煌繕?biāo)機(jī)的指令集是不一樣的，比如 arm 跟 x86 就不一樣。

gcc-core：顧明之意是 GCC 的核心部分，這部分是只包含 c 的編譯器及公共部分，而對(duì)其他語(yǔ)言（C++、Ada 等）的支持包需要另外安裝，這也是 GCC 為何如此強(qiáng)大的重要原因 。gcc-core依賴于 Binutils。

Glibc：包含了主要的 c 庫(kù)，這個(gè)庫(kù)提供了基本的例程，用于分配內(nèi)存，搜索目錄，讀寫文件，字符串處理等等。kernel 和 bootloader不需要這個(gè)庫(kù)的支持。舉例描述下上面 3 個(gè)包是如何進(jìn)行運(yùn)作的。有一個(gè) c 源文件 test.c 源碼如下：

#include
intmain(intargc,char*argv[])
{
printf("HelloLinux!!
");
return0;
}

編譯命令為：gcc -o test test.c 編譯生成 test 可執(zhí)行文件。

gcc 編譯流程分為四個(gè)步驟：預(yù)處理、編譯 、 匯編、鏈接。個(gè)人認(rèn)為預(yù)處理和編譯主要由 gcc-core 來(lái)完成，匯編和鏈接主要由 Binutils 來(lái) 完成。

那么何時(shí)用到 glibc 呢？

看到源碼中的 printf 函數(shù)沒有，這個(gè)函數(shù)在 GCC 中是以庫(kù)函 數(shù)的形式存在，這個(gè)庫(kù)函數(shù)在 glibc 庫(kù)中，在 stdio.h 頭文件中被聲明?？偟膩?lái)說(shuō)，如果真正了解了上面 3 個(gè)軟件包的作用，自然就明白 GCC 是如何工作的。

三、交叉編譯

交叉編譯（或交叉建立）是這樣一種過(guò)程，它在一種機(jī)器結(jié)構(gòu)下編譯的軟件將在另一種完全不同的機(jī)器結(jié)構(gòu)下執(zhí)行。一個(gè)常見的例子是在 PC 機(jī)上為運(yùn)行在基于 ARM、PowerPC或 MIPS 的目標(biāo)機(jī)的編譯軟件。

幸運(yùn)的是，GCC 使得這一過(guò)程所面臨的困難要比聽起來(lái)小得多。GCC 中的一般工具通常都是通過(guò)在命令行上調(diào)用命令（如 gcc）來(lái)執(zhí)行的。在使用交叉編譯的情況下，這些工具將根據(jù)它編譯的目標(biāo)而命名。

例如，要使用交叉工具鏈為 ARM 機(jī)器編譯簡(jiǎn)單的 Hello World 程序，你可以運(yùn)行如下所示的命令：使用如下命令編譯并測(cè)試這個(gè)代碼：arm-linux-gcc -o hello hello.c。

四、arm-linux-gcc

arm-linux-gcc 是基于 ARM 目標(biāo)機(jī)的交叉編譯軟件， arm-linux-gcc 跟 GCC 所需的安裝包不同，但僅僅是名字不同而已，這是為什么呢？

x86 跟 ARM 所使用的指令集是不一樣的，所以所需要的 binutils 肯定不一樣；上面提到過(guò) gcc-core 是依賴于 binutils 的，自然 ARM 跟 x86 所使用的 gcc-core 包也不一樣；glibc 一個(gè) c 庫(kù)，最終是以庫(kù)的形式存在于編譯器中，自然 ARM 所使用的 glibc 庫(kù)跟 x86 同樣也不一樣，其它的依此類推。

五、arm-elf-gcc

arm-elf-gcc 跟 arm-linux-gcc 一樣，也是是基于 ARM 目標(biāo)機(jī)的交叉編譯軟件。但是它們不是同一個(gè)交叉編譯軟件，兩者是有區(qū)別的，兩者區(qū)別主要在于使用不同的 C 庫(kù)文件。

arm-linux-gcc 使用 GNU 的 Glibc，而 arm-elf-gcc 一般使用 uClibc/uC-libc 或者使用 RedHat專門為嵌入式系統(tǒng)的開發(fā)的C庫(kù)newlib。只是所應(yīng)用的領(lǐng)域不同而已，Glibc是針對(duì)PC開發(fā)的，uClibc/uC-libc是與Glibc API兼容的小型化C語(yǔ)言庫(kù)，實(shí)現(xiàn)了Glibc部分功能。

六、uClibc/uC-libc

uClinux有兩個(gè)經(jīng)常使用的libc庫(kù)：uC-libc和uClibc。雖然兩者名字很相似，其實(shí)有差別，下面就簡(jiǎn)單的介紹一下二者的不同之處。uC -libc是最早為uClinux開發(fā)的庫(kù)，是Jeff Dionne和Kenneth Albanowski為在EKLs項(xiàng)目中支持m68000在Linux-8086 C庫(kù)源碼上移植的。

uC-libc是一個(gè)完全的libc實(shí)現(xiàn)，但其中有一些api是非標(biāo)準(zhǔn)的，有些libc的標(biāo)準(zhǔn)也沒有實(shí)現(xiàn)。uC-libc穩(wěn)定地支持 m68000，ColdFire和沒有MMU的ARM。其主要設(shè)計(jì)目標(biāo)是“小”、“輕”，并盡量與標(biāo)準(zhǔn)一致，雖然它的API和很多l(xiāng)ibc兼容，但是似乎并不像它期望的那樣和所有標(biāo)準(zhǔn)一致。

uClibc就是為了解決這個(gè)問題從uC-libc中發(fā)展出來(lái)的。它的所有API都是標(biāo)準(zhǔn)的(正確的返回類型，參數(shù)等等)，它彌補(bǔ)了uC-libc中沒有實(shí)現(xiàn)的libc標(biāo)準(zhǔn)，現(xiàn)在已經(jīng)被移植到多種架構(gòu)中。

一般來(lái)講，它盡量兼容glibc以便使應(yīng)用程序用uClibc改寫變的容易。uClibc能夠在標(biāo)準(zhǔn)的 VM linux和uClinux上面使用。為了應(yīng)用程序的簡(jiǎn)潔，它甚至可以在許多支持MMU的平臺(tái)上被編譯成共享庫(kù)。

Erik Anderson在uClibc背后做了很多的工作。uClibc支持許多系列的處理器：m68000，Coldfire，ARM，MIPS，v850， x86，i960，Sparc，SuperH，Alpha，PowerPC和Hitachi 8。不斷增加的平臺(tái)支持顯示uClibc能夠很容易的適應(yīng)新的架構(gòu)。uClinux發(fā)行版提供了環(huán)境能夠讓你選擇使用uC-libc或是uClibc編譯。

對(duì)于m68000和Coldfire平臺(tái)來(lái)說(shuō)，選擇uC-libc還是稍微好一點(diǎn)，因?yàn)樗С止蚕韼?kù)，而共享庫(kù)是這些cpu經(jīng)常使用的 libc。uClibc也幾乎和所有的平臺(tái)都能很好的工作。

newlib 是一個(gè)用于嵌入式系統(tǒng)的開放源代碼的C語(yǔ)言程序庫(kù)，由libc和libm兩個(gè)庫(kù)組成，特點(diǎn)是輕量級(jí)，速度快，可移植到很多CPU結(jié)構(gòu)上。

newlib實(shí)現(xiàn)了許多復(fù)雜的功能，包括字符串支持，浮點(diǎn)運(yùn)算，內(nèi)存分配(如malloc)和I/O流函數(shù)(printf，fprinf()等等)。其中l(wèi)ibc提供了c 語(yǔ)言庫(kù)的實(shí)現(xiàn)，而libm提供了浮點(diǎn)運(yùn)算支持。

七、C語(yǔ)言庫(kù)的選擇

在為ARM交叉編譯gcc編譯器時(shí)，對(duì)gcc指定不同的配置選項(xiàng)時(shí)，使用的C語(yǔ)言庫(kù)就不同，gcc編譯器默認(rèn)使用Glibc，也可以使用 uClibc/uC-libc(基本兼容Glibc API)，當(dāng)使用--with-newlib時(shí)，gcc編譯器不使用Glibc。當(dāng)沒有交叉編譯Glibc時(shí)，可以使用--with-newlib禁止連接Glibc而編譯bootstrap gcc編譯器。

從gcc源目錄下的config/arm中的t-linux和t-arm-elf中可以看出，不同的--target也影響gcc連接C語(yǔ)言庫(kù)，t-linux(--target=arm-linux)默認(rèn)使用Glibc，-arm-elf(--target=arm-elf)使用- Dinhibit_libc禁止連接Glibc，這時(shí)我們就可以使用newlib等其他C語(yǔ)言庫(kù)編譯GCC工具鏈。

雖然GCC工具鏈配置了不同的的C語(yǔ)言庫(kù)，但由于這些C語(yǔ)言庫(kù)都可以用來(lái)支持GCC，它們對(duì)核心數(shù)據(jù)的處理上不存在較大出入。因而arm-linux-* 和 arm-elf-* 區(qū)別主要表現(xiàn)在C語(yǔ)言庫(kù)的實(shí)現(xiàn)上，例如不同系統(tǒng)調(diào)用，不同的函數(shù)集實(shí)現(xiàn)，不同的ABI/啟動(dòng)代碼以及不同系統(tǒng)特性等微小的差別。

arm-linux- * 和 arm-elf- * 的使用沒有一個(gè)絕對(duì)的標(biāo)準(zhǔn)，排除不同庫(kù)實(shí)現(xiàn)的差異，gcc可以編譯任何系統(tǒng)。arm-linux-* 和 arm-elf-* 都可以用來(lái)編譯裸機(jī)程序和操作系統(tǒng)，只是在遵循下面的描述時(shí)系統(tǒng)程序顯得更加協(xié)調(diào)：

arm-linux-* 針對(duì)運(yùn)行l(wèi)inux的ARM機(jī)器，其依賴于指定的C語(yǔ)言庫(kù)Glibc，因?yàn)橥瑯邮褂肎libc的linux而使得arm-linux-* 在運(yùn)行l(wèi)inux的ARM機(jī)器上編譯顯得更加和諧。

arm-elf- * 則是一個(gè)獨(dú)立的編譯體系，不依賴于指定的C語(yǔ)言庫(kù)Glibc，可以使用newlib等其他C語(yǔ)言庫(kù)，不要求操作系統(tǒng)支持，當(dāng)其使用為嵌入式系統(tǒng)而設(shè)計(jì)的一些輕巧的C語(yǔ)言庫(kù)時(shí)編譯裸機(jī)程序(沒有l(wèi)inux等大型操作系統(tǒng)的程序)，如監(jiān)控程序，bootloader等能使得系統(tǒng)程序更加小巧快捷。

審核編輯：劉清