交叉編譯器中哪項必須包含

Ⅰ 交叉編譯器 arm-linux-gnueabi 和 arm-linux-gnuea

一. 什麼是ABI和EABI
1) ABI: 二進制應用程序介面(Application Binary Interface (ABI) for the ARM Architecture)
在計算機中，應用二進制介面描述了應用程序（或者其他類型）和操作系統之間或其他應用程序的低級介面.
ABI涵蓋了各種細節，如：
數據類型的大小、布局和對齊;
調用約定（控制著函數的參數如何傳送以及如何接受返回值），例如，是所有的參數都通過棧傳遞，還是部分參數通過寄存器傳遞；哪個寄存器用於哪個函數參數；通過棧傳遞的第一個函數參數是最先push到棧上還是最後；
系統調用的編碼和一個應用如何向操作系統進行系統調用；
以及在一個完整的操作系統ABI中，目標文件的二進制格式、程序庫等等。
一個完整的ABI，像Intel二進制兼容標准 (iBCS) ，允許支持它的操作系統上的程序不經修改在其他支持此ABI的操作體統上運行。
ABI不同於應用程序介面（API），API定義了源代碼和庫之間的介面，因此同樣的代碼可以在支持這個API的任何系統中編譯，ABI允許編譯好的目標代碼在使用兼容ABI的系統中無需改動就能運行。
2) EABI: 嵌入式ABI
嵌入式應用二進制介面指定了文件格式、數據類型、寄存器使用、堆積組織優化和在一個嵌入式軟體中的參數的標准約定。
開發者使用自己的匯編語言也可以使用EABI作為與兼容的編譯器生成的匯編語言的介面。
支持EABI的編譯器創建的目標文件可以和使用類似編譯器產生的代碼兼容，這樣允許開發者鏈接一個由不同編譯器產生的庫。
EABI與關於通用計算機的ABI的主要區別是應用程序代碼中允許使用特權指令，不需要動態鏈接（有時是禁止的），和更緊湊的堆棧幀組織用來節省內存。廣泛使用EABI的有Power PC和ARM.
二. gnueabi相關的兩個交叉編譯器: gnueabi和gnueabihf
在debian源里這兩個交叉編譯器的定義如下:
gcc-arm-linux-gnueabi – The GNU C compiler for armel architecture
gcc-arm-linux-gnueabihf – The GNU C compiler for armhf architecture
可見這兩個交叉編譯器適用於armel和armhf兩個不同的架構, armel和armhf這兩種架構在對待浮點運算採取了不同的策略(有fpu的arm才能支持這兩種浮點運算策略)
其實這兩個交叉編譯器只不過是gcc的選項-mfloat-abi的默認值不同. gcc的選項-mfloat-abi有三種值soft,softfp,hard(其中後兩者都要求arm里有fpu浮點運算單元,soft與後兩者是兼容的，但softfp和hard兩種模式互不兼容)：
soft : 不用fpu進行浮點計算，即使有fpu浮點運算單元也不用,而是使用軟體模式。
softfp : armel架構(對應的編譯器為gcc-arm-linux-gnueabi)採用的默認值，用fpu計算，但是傳參數用普通寄存器傳，這樣中斷的時候，只需要保存普通寄存器，中斷負荷小，但是參數需要轉換成浮點的再計算。
hard : armhf架構(對應的編譯器gcc-arm-linux-gnueabihf)採用的默認值，用fpu計算，傳參數也用fpu中的浮點寄存器傳，省去了轉換, 性能最好，但是中斷負荷高。

Ⅱ 交叉編譯器的分類

編譯器可以生成用來在與編譯器本身所在的計算機和操作系統（平台）相同的環境下運行的目標代碼，這種編譯器又叫做「本地」編譯器。另外，編譯器也可以生成用來在其它平台上運行的目標代碼，這種編譯器又叫做交叉編譯器。交叉編譯器在生成新的硬體平台時非常有用。「源碼到源碼編譯器」是指用一種高階語言作為輸入，輸出也是高階語言的編譯器。例如: 自動並行化編譯器經常採用一種高階語言作為輸入，轉換其中的代碼，並用並行代碼注釋對它進行注釋（如OpenMP）或者用語言構造進行注釋（如FORTRAN的DOALL指令）。
預處理器（preprocessor）
作用是通過代入預定義等程序段將源程序補充完整。
編譯器前端（frontend）
前端主要負責解析（parse）輸入的源代碼，由語法分析器和語意分析器協同工作。語法分析器負責把源代碼中的『單詞』（Token）找出來，語意分析器把這些分散的單詞按預先定義好的語法組裝成有意義的表達式，語句 ，函數等等。 例如「a = b + c;」前端語法分析器看到的是「a， =， b ， +， c;」，語意分析器按定義的語法，先把他們組裝成表達式「b + c」，再組裝成「a = b + c」的語句。 前端還負責語義（semantic checking）的檢查，例如檢測參與運算的變數是否是同一類型的，簡單的錯誤處理。最終的結果常常是一個抽象的語法樹（abstract syntax tree，或 AST），這樣後端可以在此基礎上進一步優化和處理。
編譯器後端（backend）
編譯器後端主要負責分析，優化中間代碼（Intermediate representation）以及生成機器代碼（Code Generation）。
一般說來所有的編譯器分析，優化，變型都可以分成兩大類：函數內（intraproceral）還是函數之間（interproceral）進行。很明顯，函數間的分析，優化更准確，但需要更長的時間來完成。

Ⅲ 在linux中安裝交叉編譯器時的解包問題

具體操作步驟如下：
1. 下載
在GCC網站上（ 3.3.1。可供下載的文件一般有兩種形式：gcc-3.3.1.tar.gz和 2，只是壓縮格式不一樣，內容完全一致，下載其中一種即可。
2. 解壓縮
根據壓縮格式，選擇下面相應的一種方式解包（以下的「%」表示命令行提示符）：
% tar xzvf gcc-3.3.1.tar.gz
或者
% tar jxvf 2
新生成的gcc-3.3.1這個目錄被稱為源目錄，用${srcdir}表示它。以後在出現${srcdir}的地方，應該用真實的路徑來替換它。用pwd命令可以查看當前路徑。
在${srcdir}/INSTALL目錄下有詳細的GCC安裝說明，可用瀏覽器打開 ml閱讀。
3. 建立目標目錄
目標目錄（用${objdir}表示）是用來存放編譯結果的地方。GCC建議編譯後的文件不要放在源目錄${srcdir]中（雖然這樣做也可以），最好單獨存放在另外一個目錄中，而且不能是${srcdir}的子目錄。
例如，可以這樣建立一個叫 gcc-build 的目標目錄（與源目錄${srcdir}是同級目錄）：

% mkdir gcc-build
% cd gcc-build
以下的操作主要是在目標目錄 ${objdir} 下進行。
4. 配置
配置的目的是決定將GCC編譯器安裝到什麼地方（${destdir}），支持什麼語言以及指定其它一些選項等。其中，${destdir}不能與${objdir}或${srcdir}目錄相同。
配置是通過執行${srcdir}下的configure來完成的。其命令格式為（記得用你的真實路徑替換${destdir}）：
% ${srcdir}/configure --prefix=${destdir} [其它選項]
例如，如果想將GCC 3.3.1安裝到/usr/local/gcc-3.3.1目錄下，則${destdir}就表示這個路徑。
% ../gcc-3.3.1/configure --prefix=/usr/local/gcc-3.3.1 --enable-threads=posix --disable-checking --enable--long-long --host=i386-redhat-linux --with-system-zlib --enable-languages=c,c++,java
將GCC安裝在/usr/local/gcc-3.3.1目錄下，支持C/C++和JAVA語言，其它選項參見GCC提供的幫助說明。
5. 編譯
% make
這是一個漫長的過程。

6. 安裝
執行下面的命令將編譯好的庫文件等拷貝到${destdir}目錄中（根據你設定的路徑，可能需要管理員的許可權）：
% make install
至此，GCC 3.3.1安裝過程就完成了。
6. 其它設置
GCC 3.3.1的所有文件，包括命令文件（如gcc、g++）、庫文件等都在${destdir}目錄下分別存放，如命令文件放在bin目錄下、庫文件在lib下、頭文件在include下等。由於命令文件和庫文件所在的目錄還沒有包含在相應的搜索路徑內，所以必須要作適當的設置之後編譯器才能順利地找到並使用它們。
6.1 gcc、g++、gcj的設置
要想使用GCC 3.3.1的gcc等命令，簡單的方法就是把它的路徑${destdir}/bin放在環境變數PATH中。我不用這種方式，而是用符號連接的方式實現，這樣做的好處是我仍然可以使用系統上原來的舊版本的GCC編譯器。
首先，查看原來的gcc所在的路徑：
% which gcc
在系統上，上述命令顯示：/usr/bin/gcc。因此，原來的gcc命令在/usr/bin目錄下。可以把GCC 3.3.1中的gcc、g++、gcj等命令在/usr/bin目錄下分別做一個符號連接：
% cd /usr/bin
% ln -s ${destdir}/bin/gcc gcc33
% ln -s ${destdir}/bin/g++ g++33
% ln -s ${destdir}/bin/gcj gcj33
這樣，就可以分別使用gcc33、g++33、gcj33來調用GCC 3.3.0的gcc、g++、gcj完成對C、C++、JAVA程序的編譯了。同時，仍然能夠使用舊版本的GCC編譯器中的gcc、g++等命令。

Ⅳ 交叉編譯器的原理

編譯是從源代碼（通常為高級語言）到能直接被計算機或虛擬機執行的目標代碼（通常為低階語言或機器語言）的翻譯過程。然而，也存在從低階語言到高階語言的編譯器，這類編譯器中用來從由高階語言生成的低階語言代碼重新生成高階語言代碼的又被叫做反編譯器。也有從一種高階語言生成另一種高階語言的編譯器，或者生成一種需要進一步處理的的中間代碼的編譯器（又叫級聯）。
典型的編譯器輸出是由包含入口點的名字和地址， 以及外部調用（到不在這個目標文件中的函數調用）的機器代碼所組成的目標文件。一組目標文件，不必是同一編譯器產生，但使用的編譯器必需採用同樣的輸出格式，可以鏈接在一起並生成可以由用戶直接執行的可執行程序。

Ⅳ 交叉編譯的基礎知識

在做實際工作之前，我想我們應該先掌握一些關於交叉編譯的基本知識，其實說白了也就是理解一些我們經常會碰到的英文單詞：
宿主機（host） ：編輯和編譯程序的平台，一般是基於X86的PC機，通常也被稱為主機。
目標機（target）：用戶開發的系統，通常都是非X86平台。host編譯得到的可執行代碼在target上運行。
prefix: 交叉編譯器的安裝位置。
xxx-xxxx-xxxxx 平台描述。
我們在主機平台上開發程序，並在這個平台上運行交叉編譯器，編譯我們的程序；而由交叉編譯器生成的程序將在目的平台上運行。這里值得說明得是平台描述，像arm-linux、i386-pc-linux2.4.3這樣的字元串我們經常會看到，其實它是用來描述平台的，它有完整格式、縮減格式和別名之分。完整格式是：CPU-製造廠商-操作系統，如sparc-sun-sunos4.1.4，說明平台所使用的CPU是sparc，製造廠商是sun，上面運行的操作系統是SunOS，版本是4.1.4。當然，我們都不願記這么長的東西，因此可以使用短格式，短格式中有選擇地去除了製造廠商、軟體版本等信息，因此我們同樣可以用sparc-sunos或sparc-sunos-sunos4來描述這個平台。如果覺得這個還是太麻煩，那就可以使用別名，sun4m就可以很簡單地描述這個平台。需要注意的是，並不是所有的平台都有別名，也不是所有的短格式都可以正確地描述平台。

Ⅵ 交叉編譯器的代碼分析

編譯器分析（compiler analysis）的對象是前端生成並傳遞過來的中間代碼，現代的優化型編譯器（optimizing compiler）常常用好幾種層次的中間代碼來表示程序，高層的中間代碼（high levelIR）接近輸入的源程序的格式，與輸入語言相關（language dependent），包含更多的全局性的信息，和源程序的結構；中層的中間代碼（middle level IR）與輸入語言無關，低層的中間代碼(Low level IR)與機器語言類似。 不同的分析，優化發生在最適合的那一層中間代碼上。
常見的編譯分析有函數調用樹（call tree），控制流程圖（Control flow graph），以及在此基礎上的 變數定義－使用，使用－定義鏈（define-use/use-define or u-d/d-u chain），變數別名分析（alias analysis），指針分析（pointer analysis），數據依賴分析（data dependenceanalysis）等。
程序分析結果是編譯器優化（compileroptimization）和程序變形（compiler transformation）的前提條件。常見的優化和變形有：函數內嵌（inlining），無用代碼刪除（Dead code elimination），標准化循環結構（loop normalization），循環體展開（loop unrolling），循環體合並，分裂（loop fusion，loop fission），數組填充（array padding），等等。 優化和變形的目的是減少代碼的長度，提高內存（memory），緩存（cache）的使用率，減少讀寫磁碟，訪問網路數據的頻率。更高級的優化甚至可以把序列化的代碼（serial code）變成並行運算，多線程的代碼（parallelized，multi-threaded code）。
機器代碼的生成是優化變型後的中間代碼轉換成機器指令的過程。現代編譯器主要採用生成匯編代碼（assembly code）的策略，而不直接生成二進制的目標代碼（binary object code）。即使在代碼生成階段，高級編譯器仍然要做很多分析，優化，變形的工作。例如如何分配寄存器（register allocatioin），如何選擇合適的機器指令（instruction selection），如何合並幾句代碼成一句等等。

Ⅶ 交叉編譯器的交叉編譯

在一種計算機環境中運行的編譯程序，能編譯出在另外一種環境下運行的代碼，我們就稱這種編譯器支持交叉編譯。這個編譯過程就叫交叉編譯。簡單地說，就是在一個平台上生成另一個平台上的可執行代碼。這里需要注意的是所謂平台，實際上包含兩個概念：體系結構（Architecture）、操作系統（Operating System）。同一個體系結構可以運行不同的操作系統；同樣，同一個操作系統也可以在不同的體系結構上運行。舉例來說，我們常說的x86 Linux平台實際上是Intel x86體系結構和Linux for x86操作系統的統稱；而x86 WinNT平台實際上是Intel x86體系結構和Windows NT for x86操作系統的簡稱。
有時是因為目的平台上不允許或不能夠安裝我們所需要的編譯器，而我們又需要這個編譯器的某些特徵；有時是因為目的平台上的資源貧乏，無法運行我們所需要編譯器；有時又是因為目的平台還沒有建立，連操作系統都沒有，根本談不上運行什麼編譯器。
交叉編譯這個概念的出現和流行是和嵌入式系統的廣泛發展同步的。我們常用的計算機軟體，都需要通過編譯的方式，把使用高級計算機語言編寫的代碼（比如C代碼）編譯（compile）成計算機可以識別和執行的二進制代碼。比如，我們在Windows平台上，可使用Visual C++開發環境，編寫程序並編譯成可執行程序。這種方式下，我們使用PC平台上的Windows工具開發針對Windows本身的可執行程序，這種編譯過程稱為native compilation，中文可理解為本機編譯。然而，在進行嵌入式系統的開發時，運行程序的目標平台通常具有有限的存儲空間和運算能力，比如常見的 ARM 平台，其一般的靜態存儲空間大概是16到32MB，而CPU的主頻大概在100MHz到500MHz之間。這種情況下，在ARM平台上進行本機編譯就不太可能了，這是因為一般的編譯工具鏈（compilation tool chain）需要很大的存儲空間，並需要很強的CPU運算能力。為了解決這個問題，交叉編譯工具就應運而生了。通過交叉編譯工具，我們就可以在CPU能力很強、存儲空間足夠的主機平台上（比如PC上）編譯出針對其他平台的可執行程序。
要進行交叉編譯，我們需要在主機平台上安裝對應的交叉編譯工具鏈（cross compilation tool chain），然後用這個交叉編譯工具鏈編譯我們的源代碼，最終生成可在目標平台上運行的代碼。

Ⅷ 交叉編譯器的工作方法

首先編譯器進行語法分析，也就是要把那些字元串分離出來。
然後進行語義分析，就是把各個由語法分析分析出的語法單元的意義搞清楚。
最後生成的是目標文件，也稱為obj文件。
再經過鏈接器的鏈接就可以生成最後的可執行代碼了。
有些時候需要把多個文件產生的目標文件進行鏈接，產生最後的代碼。這一過程稱為交叉鏈接。

Ⅸ 交叉編譯環境包括哪些工具，它的作用是什麼

首先你要知道一個軟體可能需要在多個CPU架構的平台上運行，如ARM架構，X86架構等等。
假設你要開發一個軟體目標平台是ARM，那麼你可以選擇在PC上，即X86平台上進行開發，然後使用交叉編譯工具把軟體編譯成ARM架構版本，然後才能在ARM上運行，如果只是用一般的編譯工具鏈，那麼只能編譯在當前平台上運行。
至於編譯工具鏈有哪些，具體要看你的開發平台和目標平台，會對應不同的編譯工具。

Ⅹ 交叉編譯幾種常見的報錯

交叉編譯器是一種可以在平台A上為另一種平台B編譯程序的編譯器。其中，運行交叉編譯器的平台A稱為宿主機，交叉編譯生成的目標文件的運行平台B稱為目標機。交叉編譯器的編譯過程稱為交叉編譯。
一個完整的arm-linux交叉編譯器包括arm-linux-gcc、glibc、binutils等組件。其中，arm-linux-gcc是為ARM平台編譯C程序的編譯器；glibc是嵌入式C程序所需的基本函數庫；binutils包含一組二進制工具。所以交叉編譯器又稱為交叉編譯工具鏈。
由於交叉編譯器中每個組件都有各自的版本，所以可以使用不同版本的組件來製作交叉編譯器。但是，組件之間會因版本不匹配的問題二產生錯誤。為了避免這種麻煩，建議直接使用製作好的arm-linux交叉編譯器。