在BREW專案中使用GCC編譯器

最近公司因為版權原因，不能繼續使用ads編譯器，而是換成了免費的gcc編譯器。

經過一段時間的試用磨合，現在公司裡大部分應用在生成mod時都使用gcc編譯器。小部分因為容量限制，使用的是公司購買的realview編譯器。gcc 編譯器使用thumb模式生成的mod在手機上跑有問題，尚未解決，因此mod體積要比可以使用thumb模式的realview大一些。但是購買的realview版本，一套只能裝乙個機器。一套realview幾萬塊錢，每台機器裝又不現實。即使使用telnet遠端編譯，也不如本機上裝的gcc方便。

使用gcc的過程中還是頗費了一番周折的，下面記錄一下遇到的困難，希望能給大家提供一些幫助。

1.gcc版本

在brew forum上了解到brew圈子裡，gnude和winarm是兩個用的比較多的windows下的arm-gcc編譯環境(還有乙個更新的yagarto)。gnude的gcc編譯器是3.x版本，winarm的是4.x版本。gnude在win7上生成原始檔依賴檔案列表時編譯器會死掉，因此順勢就用了版本較新的winarm。

2.搭配工具

專案要有乙個針對gcc的makefile。這個makefile可以自己寫，也可以使用brew sdk tools 1.1.1 sp06帶的vc外掛程式自動生成。如果是自動生成的話，注意要配好gcc的環境變數。例如我的winarm裝在d盤根目錄下，環境變數就要設為

gcchome=d:/winarm

gcclibpath=d:/winarm/lib/gcc/arm-elf/4.1.1

path裡也要加入d:/winarm/bin

3.鏈結指令碼問題

需要給gcc鏈結器提供乙個鏈結指令碼，如果使用brew sdk tools 1.1.1 sp06的話，有乙個預設的鏈結指令碼elf2mod.x。如果多檔案工程，使用-o2或-os編譯選項的話，這個鏈結指令碼會有問題，它不能保證aeemod_load放在mod的0位址處，而對於brew程式而言，這又是必須的。我稍微修改了下elf2mod.x檔案，這樣定義.text段，就可以使用優化編譯選項了。

.text : at(0)

"aeemod*.o"(.text.aeemod_load) /*add by zp,10.06.08*/

*(.text .stub .text.* .gnu.linkonce.t* .glue_7t .glue_7)

} :er_ro =0

4.鏈結錯誤

剛開始使用winarm時，鏈結器總報告這樣的錯誤

undefined reference to `abort'

undefined reference to `_sbrk_r'

開始我以為是沒有鏈結正確的gcc庫，後來發現winarm使用了乙個叫做newlib的庫，這個庫里有些與硬體相關的底層函式是需要使用者自己定義的。而程式裡使用這些底層功能的地方是乙個叫做__cxa_pure_virtual的系統函式（純虛函式呼叫的錯誤處理函式）。我們只要將這個函式定義成空就可以繞過這個問題了。

void __cxa_pure_virtual (void) {}

5.寬字串

使用aechar的話，gcc預設是4個位元組，與brew標準不符。需要使用乙個編譯選項-fshort-wchar，否則使用寬字串的地方會出錯。

6.浮點數問題

gcc的double格式可以稱為middle endian（即dword內部是little endian,dword之間是big endian），這與手機上的brew實現是不一致的。因此如果呼叫brew的浮點數介面，例如fadd / wstrtofloa等，得到結果是不正確的。其實一般的加減乘除，直接使用運算子就可以了（gcc的這個解決方案支援全域性變數，進而支援浮點數運算）。如果要使用fsqt等函式，可以在執行時動態判斷浮點數格式，在與brew接**互時進行必要的轉換。

7.參考資料

b.使用gnu gcc建立brew應用

中文的，還附帶乙份makefile模板

在BREW專案中使用GCC編譯器

在專案中使用ExtJS

在專案中使用springmvc

ButterKnife在專案中使用

在BREW專案中使用GCC編譯器

在專案中使用ExtJS

在專案中使用springmvc

ButterKnife在專案中使用

相關推薦