gcc、arm-linux-gcc 和 arm-elf-gcc的關係？

資料來源: https://mp.weixin.qq.com/s/OY7MlS7yA9ahEFxvrI1VfQ

一、GCC簡介

    The GNU Compiler Collection，通常簡稱GCC，是一套由GNU 開發的編譯器集，為什麼是編輯器集而不是編譯器呢？那是因為它不僅支持C 語言編譯，還支持C++， Ada，Objective C 等許多語言。另外GCC 對硬件平台的支持，可以所無所不在，它不僅支持X86處理器架構, 還支持ARM, Motorola 68000, Motorola 8800，AtmelAVR，MIPS 等處理器架構。

二、GCC的組成結構

    GCC 內部結構主要由Binutils、gcc-core、Glibc 等軟件包組成。

        ◆Binutils：它是一組開發工具，包括連接器，彙編器和其他用於目標文件和檔案的工具。關於Binutils 的介紹可以參考Binutils 簡單介紹。這個軟件包依賴於不同的目標機的平台。因為不同目標機的指令集是不一樣的，比如arm 跟x86 就不一樣。

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

        ◆Glibc：包含了主要的c 庫，這個庫提供了基本的例程，用於分配內存，搜索目錄，讀寫文件，字符串處理等等。kernel 和bootloader不需要這個庫的支持。

舉例描述下上面3 個包是如何進行運作的。有一個c 源文件test.c 源碼如下：

#include<stdio.h>
int main(int argc, char *argv[])
{
    printf("Hello Linux!!\n");
    return 0;
}

    編譯命令為：gcc -o test test.c 編譯生成test 可執行文件。gcc 編譯流程分為四個步驟：預處理、編譯、彙編、鏈接。個人認為預處理和編譯主要由gcc-core 來完成，彙編和鏈接主要由Binutils 來完成。

    那麼何時用到glibc 呢？看到源碼中的printf 函數沒有，這個函數在GCC 中是以庫函數的形式存在，這個庫函數在glibc 庫中，在stdio.h 頭文件中被聲明。總的來說，如果真正了解了上面3 個軟件包的作用，自然就明白GCC 是如何工作的。

三、交叉編譯

    交叉編譯（或交叉建立）是這樣一種過程，它在一種機器結構下編譯的軟件將在另一種完全不同的機器結構下執行。一個常見的例子是在PC 機上為運行在基於ARM、PowerPC或MIPS 的目標機的編譯軟件。

    幸運的是，GCC 使得這一過程所面臨的困難要比聽起來小得多。GCC 中的一般工具通常都是通過在命令行上調用命令（如gcc）來執行的。在使用交叉編譯的情況下，這些工具將根據它編譯的目標而命名。

    例如，要使用交叉工具鍊為ARM 機器編譯簡單的Hello World 程序，你可以運行如下所示的命令：使用如下命令編譯並測試這個代碼：arm-linux-gcc -o hello hello.c。

四、arm-linux-gcc

    arm-linux-gcc 是基於ARM 目標機的交叉編譯軟件， arm-linux-gcc 跟GCC 所需的安裝包不同：

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

五、arm-elf-gcc

    arm-elf-gcc 跟arm-linux-gcc 一樣，也是是基於ARM 目標機的交叉編譯軟件。但是它們不是同一個交叉編譯軟件，兩者是有區別的，兩者區別主要在於使用不同的C 庫文件。

    arm-linux-gcc 使用GNU 的Glibc，而arm-elf-gcc 一般使用uClibc/uC-libc 或者使用RedHat專門為嵌入式系統的開發的C庫newlib。只是所應用的領域不同而已，Glibc是針對PC開發的，uClibc/uC-libc是與Glibc API兼容的小型化C語言庫，實現了Glibc部分功能。

六、uClibc/uC-libc 

    uClinux有兩個經常使用的libc庫：uC-libc和uClibc。雖然兩者名字很相似，其實有差別，下面就簡單的介紹一下二者的不同之處。uC -libc是最早為uClinux開發的庫，是Jeff Dionne和Kenneth Albanowski為在EKLs項目中支持m68000在Linux-8086 C庫源碼上移植的。

        ◆uC-libc是一個完全的libc實現，但其中有一些api是非標準的，有些libc的標準也沒有實現。uC-libc穩定地支持m68000，ColdFire和沒有MMU的ARM。其主要設計目標是“小”、“輕”，並儘量與標準一致，雖然它的API和很多libc兼容，但是似乎並不像它期望的那樣和所有標準一致。

        ◆uClibc就是為了解決這個問題從uC-libc中發展出來的。它的所有API都是標準的(正確的返回類型，參數等等)，它彌補了uC-libc中沒有實現的libc標準，現在已經被移植到多種架構中。一般來講，它盡量兼容glibc以便使應用程序用uClibc改寫變的容易。

        ◆uClibc能夠在標準的VM linux和uClinux上面使用。為了應用程序的簡潔，它甚至可以在許多支持MMU的平台上被編譯成共享庫。Erik Anderson在uClibc背後做了很多的工作。uClibc支持許多系列的處理器：m68000，Coldfire，ARM，MIPS，v850， x86，i960，Sparc，SuperH，Alpha，PowerPC和Hitachi 8。

    不斷增加的平台支持顯示uClibc能夠很容易的適應新的架構。uClinux發行版提供了環境能夠讓你選擇使用uC-libc或是uClibc編譯。對於m68000和Coldfire平台來說，選擇uC-libc還是稍微好一點，因為它支持共享庫，而共享庫是這些cpu經常使用的libc。uClibc也幾乎和所有的平台都能很好的工作。

    newlib 是一個用於嵌入式系統的開放源代碼的C語言程序庫，由libc和libm兩個庫組成，特點是輕量級，速度快，可移植到很多CPU結構上。newlib實現了許多複雜的功能，包括字符串支持，浮點運算，內存分配(如malloc)和I/O流函數(printf，fprinf()等等)。其中libc提供了c 語言庫的實現，而libm提供了浮點運算支持。

七、C語言庫的選擇

    在為ARM交叉編譯gcc編譯器時，對gcc指定不同的配置選項時，使用的C語言庫就不同，gcc編譯器默認使用Glibc，也可以使用uClibc/uC-libc(基本兼容Glibc API)，當使用–with-newlib時，gcc編譯器不使用Glibc。當沒有交叉編譯Glibc時，可以使用–with-newlib禁止連接Glibc而編譯bootstrap gcc編譯器。

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

    雖然GCC工具鏈配置了不同的的C語言庫，但由於這些C語言庫都可以用來支持GCC，它們對核心數據的處理上不存在較大出入。因而arm-linux-* 和arm-elf-*區別主要表現在C語言庫的實現上，例如不同系統調用，不同的函數集實現，不同的ABI/啟動代碼以及不同系統特性等微小的差別。

    arm-linux-*和arm-elf-*的使用沒有一個絕對的標準，排除不同庫實現的差異，gcc可以編譯任何系統。arm-linux-*和arm-elf-*都可以用來編譯裸機程序和操作系統，只是在遵循下面的描述時系統程序顯得更加協調：

        ◆arm-linux-*針對運行linux的ARM機器，其依賴於指定的C語言庫Glibc，因為同樣使用Glibc的linux而使得arm-linux-*在運行linux的ARM機器上編譯顯得更加和諧。

        ◆arm-elf-*則是一個獨立的編譯體系，不依賴於指定的C語言庫Glibc，可以使用newlib等其他C語言庫，不要求操作系統支持，當其使用為嵌入式系統而設計的一些輕巧的C語言庫時編譯裸機程序(沒有linux等大型操作系統的程序)，如監控程序，bootloader等能使得系統程序更加小巧快捷。