幾種Linux下嵌入式開發環境的簡單介紹

　　Scratchbox

　　Scratchbox 的故事要從buildroot講起（這不一定是scratchbox開發者的故事，只是依據我個人的認識）。buildroot可以從頭開始，先構造編譯器和基本開發環境，然后根據用戶配配置構造一個適用于目標平臺的根文件系統。這個文件系統可以有許多用法，例如，做為initrd或通過NFS輸出給目標系統使用。為了減少交叉編譯軟件帶來的麻煩，可以配置buidroot創建一套目標系統的編譯環境（Gcc、binutils、lib等），這樣用戶可以通過這個基本文系統在目標系統上直接本地編譯軟件。如果目標系統性能足夠的話，buildroot的任務到此就基本結束了。對于嵌入式系統的開發者來說，在目標系統上直接編譯代碼卻不一定都能夠實現，因為多數情況下，我們的目標平臺處理器性能并不會那么高，這樣，我們就不得不面對一個兩難的選擇：

　　繼續通過buildroot編譯其它的軟件，性能會高許多，但每個軟件都需要進行交叉編譯相關的改造；

　　在目標平臺上編譯軟件，對于只有幾十或幾百兆的低性能核來說，編譯一個核心可能會讓你等上半天的時間；

　　有沒有好的辦法解決性能和交叉編譯的問題呢？先分析一下通過buildroot交叉編譯不能解決的問題。Buildroot只在一定程度上對目標平臺進行了模擬，但仍有一些是無法實現的，例如，當目標平臺不同于主機平臺時，不能生成并運行目標平臺的中間代碼。這樣，許多通過autotools （autoconf/automake）配置的軟件就可能會出現問題。例如，configure 腳本有時會生成一些中間代碼，并試圖運行以確認開發環境中是否存在某個庫文件或頭文件，對于在X86上編譯基于uClibc X86目標平臺代碼可能不會出現問題，但如果目標平臺是X86以外的平臺，編譯就可能會中斷；又如，configure腳本確認編譯器是否工作，會試圖編譯一個包含空的主程序的代碼并運行，實際一個可運行于目標平臺的 a.out 確實生成了，也可以正常運行于目標平臺，但是這個測試會因為 a.out 被運行在主機系統上而錯誤的中斷。這些問題一些被 buildroot 通過補丁或復雜的 configure 參數解決了，某些中間執行文件，則通過HOSTCC（主機上的CC）來生成并運行以生成最終文件。目前buildroot包含的軟件或多或少都會有一些這樣的補丁，而且開發者一旦深入到對軟件的定制，就會不停的被這些問題所困擾。

　　Scratchbox相比于buildroot有幾方面的改進：

　　運行于 chroot 的環境，完全獨立于主機，編譯過程將基本與主機系統無關（并且scratchbox修改了一些庫，使得普通用戶可以chroot到編譯環境中，并且多個用戶可以同時使用一套Scratchbox開發套件和完全獨立的用戶資源）；

　　透過qemu模擬運行或sbrsh解決中間執行文件或類似configure測試文件運行的問題；

　　對(chroot后)的系統進行修定，達到足以欺騙大多數軟件的效果，這并不是指的讓軟件可以不進行改造就可以 交叉 編譯，而是使軟件 誤認為 這就是在目標平臺上編譯；

　　不過 Scratchbox 目前還只能編譯 ARM 和 x86 的代碼，不能支持 buildroot 所支持的 ppc、mips等。

　　本文不詳述每一種環境，因此各個軟件都只是點到為止(雖然可以講得更詳細一些，但這些內容還是獨立出來比較好一些），不過這里還是引入一個很簡單的示例，根據 scratchbox 網站上的文檔，安裝完成后，進行簡單配置就可以使用了（Debian用戶的安裝可以更簡單，因為該站提供Deb包，直接apt-get就行了）。通過 /scratchbox/login 登入開發環境，通過sb-menu配置一個基于 ARM 的環境（其中 Select CPU-transparency method 選qemu不要先sbrsh），然后寫一個 helloword.c，編譯并運行之。 通過ldd可以看到，在沒有任可改動的情況下，順利的生成了ARM ELF，但在 scratchbox 里卻可以在X86的主機上正常的運行！

　　[sbox-redice: ~] >gcc -o hello hello.c

　　[sbox-redice: ~] >file hellohello:

　　ELF 32-bit LSB executable, ARM, version 1 (ARM),

　　for GNU/Linux 2.0.0,dynamically linked (uses shared libs),

　　not stripped[sbox-redice: ~] >

　　./hellohelo world![sbox-redice: ~] >