uclibc交叉編譯
簡介
交叉編譯工具鏈是一個由編譯器、連接器和解釋器組成的綜合開發環境，交叉編譯工具鏈主要由binutils、gcc和glibc 3個部分組成。有時出於減小libc庫大小的考慮，也可以用別的c庫來代替glibc，例如uClibc、dietlibc和newlib。交叉編譯工具鏈主要包括針對目標系統的編譯器gcc、目標系統的二進制工具binutils、目標系統的標准c庫glibc和目標系統的Linux內核頭文件。第一個步驟就是確定目標平台。每個目標平台都有一個明確的格式，這些信息用於在構建過程中識別要使用的不同工具的正確版本。因此，當在一個特定目標機下運行GCC時，GCC便在目錄路徑中查找包含該目標規范的應用程序路徑。GNU的目標規范格式為CPU-PLATFORM-OS。例如，建立基於ARM平台的交叉工具鏈，目標平台名為arm-linux-gnu。
交叉編譯工具鏈的製作方法
分步編譯和安裝交叉編譯工具鏈所需要的庫和源代碼，最終生成交叉編譯工具鏈。
通過Crosstool腳本工具來實現一次編譯生成交叉編譯工具鏈。
直接通過網上（ftp.arm.kernel.org.uk）下載已經製作好的交叉編譯工具鏈。
方法1相對比較困難，適合想深入學習構建交叉工具鏈的讀者。如果只是想使用交叉工具鏈，建議使用方法2或方法3構建交叉工具鏈。方法3的優點不用多說，當然是簡單省事，但與此同時該方法有一定的弊端就是局限性太大，因為畢竟是別人構建好的，也就是固定的沒有靈活性，所以構建所用的庫以及編譯器的版本也許並不適合你要編譯的程序，同時也許會在使用時出現許多莫名的錯誤，建議你慎用此方法。
方法1：分步構建交叉編譯工具鏈
下載所需的源代碼包
建立工作目錄
建立環境變數
編譯、安裝Binutils
獲取內核頭文件
編譯gcc的輔助編譯器
編譯生成glibc庫
編譯生成完整的gcc
由於在問答中的篇幅，我不能細述具體的步驟，興趣的同學請自行閱讀開源共創協議的《Linux from scratch》，網址是：linuxfromscratch dot org
。
方法2:用Crosstool工具構建交叉工具鏈（推薦）
Crosstool是一組腳本工具集，可構建和測試不同版本的gcc和glibc，用於那些支持glibc的體系結構。它也是一個開源項目，下載地址是kegel dot com/crosstool。用Crosstool構建交叉工具鏈要比上述的分步編譯容易得多，並且也方便許多，對於僅僅為了工作需要構建交叉編譯工具鏈的你，建議使用此方法。
運行which makeinfo，如果不能找見該命令，在解壓texinfo-4.11.tar.bz2，進入texinfo-4.11目錄，執行./configure&&make&&make install完成makeinfo工具的安裝
准備文件：
下載所需資源文件linux-2.4.20.tar.gz、binutils-2.19.tar.bz2、gcc-3.3.6.tar.gz、glibc- 2.3.2.tar.gz、glibc-linuxthreads-2.3.2.tar.gz和gdb-6.5.tar.bz2。然後將這些工具包文件放在新建的$HOME/downloads目錄下，最後在$HOME/目錄下解壓crosstool-0.43.tar.gz，命
令如下：
#cd$HOME/
#tar–xvzfcrosstool-0.43.tar.gz
建立腳本文件
接著需要建立自己的編譯腳本，起名為arm.sh，為了簡化編寫arm.sh，尋找一個最接近的腳本文件demo-arm.sh作為模板，然後將該腳本的內容復制到arm.sh，修改arm.sh腳本，具體操作如下：
# cd crosstool-0.43
# cp demo-arm.sh arm.sh
# vi arm.sh
修改後的arm.sh腳本內容如下：
#!/bin/sh
set-ex
TARBALLS_DIR=$HOME/downloads#定義工具鏈源碼所存放位置。
RESULT_TOP=$HOME/arm-bin#定義工具鏈的安裝目錄
exportTARBALLS_DIRRESULT_TOP
GCC_LANGUAGES="c,c++"#定義支持C,C++語言
exportGCC_LANGUAGES
#創建/opt/crosstool目錄
mkdir-p$RESULT_TOP
#編譯工具鏈，該過程需要數小時完成。
eval'catarm.datgcc-3.3.6-glibc-2.3.2.dat'shall.sh--notest
echoDone.
建立配置文件
在arm.sh腳本文件中需要注意arm-xscale.dat和gcc-3.3.6-glibc-2.3.2.dat兩個文件，這兩個文件是作為Crosstool的編譯的配置文件。其中arm.dat文件內容如下，主要用於定義配置文件、定義生成編譯工具鏈的名稱以及定義編譯選項等。
KERNELCONFIG='pwd'/arm.config#內核的配置
TARGET=arm-linux#編譯生成的工具鏈名稱
TARGET_CFLAGS="-O"#編譯選項
gcc-3.3.6-glibc-2.3.2.dat文件內容如下，該文件主要定義編譯過程中所需要的庫以及它定義的版本，如果在編譯過程中發現有些庫不存在時，Crosstool會自動在相關網站上下載，該工具在這點上相對比較智能，也非常有用。
BINUTILS_DIR=binutils-2.19
GCC_DIR=gcc-3.3.6
GLIBC_DIR=glibc-2.3.2
LINUX_DIR=linux-2.6.10-8(根據實際情況填寫)
GDB_DIR=gdb-6.5
執行腳本
將Crosstool的腳本文件和配置文件准備好之後，開始執行arm.sh腳本來編譯交叉編譯工具。具體執行命令如下：
#cdcrosstool-0.43
#./arm.sh
經過數小時的漫長編譯之後，會在/opt/crosstool目錄下生成新的交叉編譯工具，其中包括以下內容：
arm-linux-addr2linearm-linux-g++arm-linux-ldarm-linux-size
arm-linux-ararm-linux-gccarm-linux-nmarm-linux-strings
arm-linux-asarm-linux-gcc-3.3.6arm-linux-objarm-linux-strip
arm-linux-c++arm-linux-gccbugarm-linux-objmpfix-embedded-paths
arm-linux-c++filtarm-linux-gcovarm-linux-ranlib
arm-linux-cpparm-linux-gprofarm-linux-readelf
添加環境變數
然後將生成的編譯工具鏈路徑添加到環境變數PATH上去，添加的方法是在系統/etc/ bashrc文件的最後添加下面一行，在bashrc文件中添加環境變數
export PATH=/home/jiabing/gcc-3.3.6-glibc-2.3.2/arm-linux-bin/bin:$PATH
至此，arm-linux下的交叉編譯工具鏈已經完成，現在就可以使用arm-linux-gcc來生成試驗箱上的程序了！
㈡ 如何在ARM9上進行嵌入式Linux代碼移植
嵌入式系統開發就是對於除了電腦之外的所有電子設備上操作系統的開發，開發對象有手機，掌上電腦，機電系統等。 嵌入式系統開發流程：
第一步：建立開發環境
操作系統一般使用Redhat Linux，選擇定製安裝或全部安裝，通過網路下載相應的GCC交叉編譯器進行安裝(比如，arm-linux-gcc、arm-uclibc-gcc)，或者安裝產品廠家提供的相關交叉編譯器；
第二步：配置開發主機
配置MINICOM，一般的參數為波特率115200 Baud/s，數據位8位，停止位為1，9，無奇偶校驗，軟體硬體流控設為無。在Windows下的超級終端的配置也是這樣。MINICOM軟體的作用是作為調試嵌入式開發板的信息輸出的監視器和鍵盤輸入的工具。配置網路主要是配置NFS網路文件系統，需要關閉防火牆，簡化嵌入式網路調試環境設置過程。
第三步：建立引導裝載程序BOOTLOADER
從網路上下載一些公開源代碼的BOOTLOADER，如U．BOOT、BLOB、VIVI、LILO、ARM-BOOT、RED-BOOT等，根據具體晶元進行移植修改。有些晶元沒有內置引導裝載程序，比如，三星的ARV17、ARM9系列晶元，這樣就需要編寫開發板上FLASH的燒寫程序，可以在網上下載相應的燒寫程序，也有Linux下的公開源代碼的J-FLASH程序。如果不能燒寫自己的開發板，就需要根據自己的具體電路進行源代碼修改。這是讓系統可以正常運行的第一步。如果用戶購買了廠家的模擬器比較容易燒寫FLASH，雖然無法了解其中的核心技術，但對於需要迅速開發自己的應用的人來說可以極大提高開發速度。
㈢ ubuntu系統系交叉編譯出現command not found錯誤，謝謝
1、核實 mips-openwrt-linux-uclibc-gcc 是否有執行許可權
chmod +x mips-openwrt-linux-uclibc-gcc
2、核實 mips-openwrt-linux-uclibc-gcc 是否為快捷鏈接，
1）其鏈接的gcc是否有執行許可權
2）其鏈接是否在正確的位置
3、核實PATH路勁是否添加正確(相信樓主是加正確了的)
根據樓主截圖，這個環境變數是有的，一般應該檢查1、2點
㈣ 嵌入式linux系統開發的具體步驟
第一步、建立交叉編譯環境
沒有交叉開發經驗的讀者，可能一時很難接受這個概念。首先，要明白兩個概念：一般
我們工作的機器，稱為開發機、主機；我們製作好的系統將要放到某台機器，如手機或另一
台PC機，這台機我們稱為目標主機。
我們一般開發機上已經有一套開發工具，我們稱之為原生開發套件，我們一般就是用它
們來寫程序，那麼，那什麼又是交叉編譯環境呢？其實一點也不神秘，也就是在開發機上再
安裝一套開發工具，這套開發工具編譯出來的程序，如內核、系統工作或者我們自己的程序，
是放在目標主機上運行的。
那麼或許有初學者會問，直接用原生開發工具為目標主機編譯程序不就完了？至少我當
初是這么想的。一般來說，我們的開發機都是X86 平台，原生開發套件開發的工具，也針
對X86 平台，而我們的目標主機可能是PowerPC、IXP、MIPS……所以，我們的交叉編譯
環境是針對某一類具體平台的。
一般來講，交叉開發環境需要二進制工具程序、編譯器、C鏈接庫，嵌入式開發常用的
這三類軟體是：
Binutils
Gcc
uClibc
當然，GNU包含的工具套件不僅於此，你還要以根據實際需要，進行選擇
第二步、編譯內核
開發工具是針對某一類硬體平台，內核同樣也是。這一步，我們需要用第一步中建立的
工具，對內核進行編譯，對於有內核編譯經驗的人來說，這是非常簡單的；
第三步、建立根文件系統
也就是建立我們平常看到的bin、dev、proc……這一大堆目錄，以及一些必備的文件；
另外，我們還需要為我們的目標系統安裝一些常用的工具軟體，如ls、ifconfig……當然，
一個辦法是找到這些工具的源代碼，用第一步建立的交叉編譯工具來編譯，但是這些軟體一
是數量多，二是某些體積較大，不適合嵌入式系統，這一步，我們一般都是用busybox來完
成的，包括系統引導軟體init；
最後，我們為系統還需要建立初始化的引導文件，如inittab……
㈤ arm-linux-gcc 和 arm-elf-gcc 的區別
在基於ARM的嵌入式系統開發中，常常用到交叉編譯的GCC工具鏈有兩種：
arm-linux-*和 arm-elf-*，兩者區別主要在於使用不同的C庫文件。arm-linux-*使用
GNU的Glibc，而arm-elf-*一般使用 uClibc/uC-libc或者使用REDHAT專門為嵌入式系統
的開發的C庫newlib.Glibc。uClibc/uC-libc以及 newlib都是C語言庫文件，只是所應
用的領域不同而已，Glibc是針對PC開發的，uClibc/uC-libc是與Glibc API兼容的小型
化C語言庫，實現了Glibc部分功能。
關於uClibc/uC-libc的說明，詳見如下：
There are two libc libraries commonly used with uClinux. uC-libc and
uClibc. They are quite different despite their similar names. Here is a
quick overview of how they are different.
uC-libc is the original library for uClinux. It was based on sources
from the Linux-8086 C library which was part of the ELKs project with m68000
support added by Jeff Dionne and Kenneth Albanowski. It is a fairly complete
libc implementation, however, some of the API's are a little non-standard
and quite a few common libc routines are not present. Currently it has
stable support for m68000, ColdFire and ARM (Non-MMU) architectures. It was
primary design goal is to be small and light weight. It does try to conform
to any standards, although its API tries to be compatible with most libcs,
it is not always exactly the same.
The uClinux distribution provides an environment that can compile using
either uC-libc or uClibc depending on your needs. For m68000 and Coldfire
platforms it is generally better to chose uC-libc as it supports shared
libraries and is the most commonly used libc for these CPUs. uClibc also
works quite well with almost all platforms supported by the distribution.
Which libc you choose to use will be decided by your requirements
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也幾乎和所有的平台都能很
好的工作。選擇哪種libc取決於你的需求。
newlib 是一個用於嵌入式系統的開放源代碼的C語言程序庫，由libc和libm兩個庫組
成，特點是輕量級，速度快，可移植到很多CPU結構上。newlib實現了許多復雜的功
能，包括字元串支持，浮點運算，內存分配(如malloc)和I/O流函數(printf，fprinf()
等等)。其中libc提供了c 語言庫的實現，而libm提供了浮點運算支持。
在為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等
能使得系統程序更加小巧快捷。
Linaro prebuilt toolchain does support both hard and soft floating
point. You can get it from https://launchpad.net/linaro-toolchain-binaries/+milestone/2012.08 try: ./arm-linux-gnueabihf-gcc -print-multi-lib
The default configure is --with-arch=armv7-a --with-tune=cortex-a9
--with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
To use soft floating, you need options: -marm -march=armv4t -mfloat-abi=soft.
In your case, please try to change -march=armv5 to "-march=armv4t"
If you want to change to configure to cortex-a8 and armv5. You need
* Change cortex-a9 to cortex-a8 in
samples/linaro-arm-linux-gnueabihf/crosstool.config
* Change armv4t to armv5 in
contrib/linaro/patches/gcc/linaro-4.7-2012.08/multilib.patch,
Then follow the instructions to rebuild the toolchain
(contrib/linaro/doc/README.txt)
BTW: crosstool-ng-linaro does not support multilib for eglibc. It uses
the prebuilt sysroot from Ubuntu Precise. If it does not work for you,
please use the latest crosstool-ng from http://crosstool-ng.org/.
㈥ 交叉編譯工具鏈 arm-arago-linux-gnueabi-gcc 中的arago和gnueabi代表什麼意思
arm-arago-linux-gnueabi-gcc
arm ：CPU Architecture
arago： Hardware Platform or Vendor
linux：Operating System
gnueabi： C Library
arago 那個段落，表示的是供應商，對於 arm 這里也可以是 hardfloat 或者 softfloat ，也就是使用的是硬浮點還是軟浮點。當然其實這個東西是在編譯 gcc 時，通過 --with-float= 指定而不是通過這里進行識別蘆州。但有的時候，一些編譯腳本會識別這里來確定浮點運算器是軟是硬。
gnueabi 是 C 函數庫的使用，比如 gnu 是 GNU C Library ，也就是 glibc 。對應的還有 uclibc 。附加的 eabi 其實是說，使用的是新的 EABI 二進制介面 Embedded application binary interface 。這個嵌入式專用介面比老的更好用，效率更高而且支持新的一些硬體功能。碼伍老的教 OABI 。當然，同 float 一樣可以通過參數直接定義。
這一大堆聯合起來，只是為了直觀的表現並且區別使用用途和功能定義。沒有必陪模蔽要太過於關注。