『壹』 c語言用什麼編譯器
c語言可以用的編譯器有很多，包括MicrosoftVisualC++、MyEclipse、TurboC和gcc編譯器等。『貳』 如何在windows上用ndk交叉編譯其他平台程序
目標 ：編譯arm64的.so庫
編譯方法：理論上應該有兩種交叉編譯方法，法一，在linux伺服器上安裝交叉工具鏈，直接用交叉工具鏈進行編譯鏈接；法二，使用ndk完成交叉編譯，因為
ndk已經安裝好交叉編譯工具鏈，以及相關的系統庫和系統頭文件了。這兩種方法的區別在於，linux伺服器上的編譯使用的makefile和ndk使用的.mk
文件顯然不同。原因是ndk作為一個集成編譯環境，制定了一套特定的規則用於生成最終的編譯腳本。
這里簡單總結下，如何在windows用ndk進行交叉編譯arm64目標平台的.so庫：
step1:找到ndk開發工具包，官網之類的都可以下載，android-ndk64-r10-windows-x86_64.rar文件
step2:解壓上述ndk工具包，將包含程序源文件和頭文件的文件夾testProject都放入android-ndk-r10下的samples目錄下。
放在其他地方當然也可以，但是後續相對路徑之類的不太好加，既然其他例子都放這，把代碼放這編譯是最保險的了。
step3:在testProject中增加一個jni的文件夾，必須要添加！！！！！！
step4:在jni文件夾中，添加一個Android.mk的文件，必須要添加！！！！！
step5:在jni文件夾中，添加一個Application.mk的文件與Android.mk並列，必須要添加！！！！！
step6:Android.mk和Application.mk合起來就類似於linux環境下的makefile編譯文件。
如何寫Android.mk，可以參考例子helllo-jni中jni文件夾下的Android.mk。
LOCAL_PATH:=$(call my-dir) #必須要寫的
include $(CLEAR_VARS) #必須要寫的
LOCAL_MODULE:=hello-jni #編譯出來的模塊名稱
LOCAL_SRC_FILES:=hello-jni.c #制定編譯的源文件名稱
include $(BUILD_SHARED_LIBRARY)#放在最後
除了上述變數之外，還有其他的指定的變數，
LOCAL_CFLAGS，用於指定編譯選項，這個和makefile中是完全一樣的，可以指定編譯選項-g，也可以指定編譯宏及宏值
LOCAL_LDLIBS，用於指定鏈接的依賴庫，這個可以makefile也是完全一樣的，可以指定鏈接庫用-l庫名，以及指定庫搜索路徑用_L路徑名
LOCAL_STATIC_LIBRARIES，指定鏈接的靜態庫名，makefile中沒有
LOCAL_C_INCLUDES，用於指定編譯頭文件的路徑，和makefile中不同，路徑前不需要加-I，直接寫路徑即可，可以是相對路徑或絕對路徑，
多個路徑之間用空格隔開。
編寫上述Android.mk碰到的問題有，
(1)使用默認的系統自動載入stl庫頭文件總是出錯，只好手動在LOCAL_STATIC_LIBRARIES指定sources/cxx-stl/stlport/stlport來完成對#include<string>這種c++形式的頭文件載入
(2)使用$(SYSROOT)/usr/include來完成對系統庫頭文件的載入，結果找不到sem_t符號，只好指定platforms/android-L/arch-arm64/usr/include
step7:Application.mk編寫
APP_STL指定使用的stl移植庫，動態或者靜態都行
APP_CPPFLAGS，指定app編譯的編譯選項
APP_ABI指定abi規范類型，例如arm64-v8a，也可以寫成ALL就是把所有的類型全部編一編
APP_PLATFORM指定編譯的platform名稱，這里可以寫成android-L或者不指定全編。
step8:編譯完成後，運行。
啟動cmd，使用cd /D進行到testProject的jni目錄下
step9:將android-ndk-r10下的ndk-build.cmd直接拖拽到cmd中，此時直接敲回車，就可以編譯了。當然也可以加一個 clean，清除編譯中間文件。
step10:檢查下編譯結果，編譯成功後在testProject中多了兩個文件夾與jni並列的，libs和obj。
編譯鏈接後的結果就在libs中！
『叄』 交叉編譯環境包括哪些工具，它的作用是什麼
首先你要知道一個軟體可能需要在多個CPU架構的平台上運行，如ARM架構，X86架構等等。
假設你要開發一個軟體目標平台是ARM，那麼你可以選擇在PC上，即X86平台上進行開發，然後使用交叉編譯工具把軟體編譯成ARM架構版本，然後才能在ARM上運行，如果只是用一般的編譯工具鏈，那麼只能編譯在當前平台上運行。
至於編譯工具鏈有哪些，具體要看你的開發平台和目標平台，會對應不同的編譯工具。
『肆』 交叉編譯器 arm-linux-gnueabi 和 arm-linux-gnueabihf 的區別
自己之前一直沒搞清楚這兩個交叉編譯器到底有什麼問題,特意google一番,總結如下,希望能幫到道上和我有同樣困惑的兄弟…..
一. 什麼是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中的浮點寄存器傳，省去了轉換, 性能最好，但是中斷負荷高。
把以下測試使用的c文件內容保存成mfloat.c：
#include <stdio.h>
int main(void)
{
double a,b,c;
a = 23.543;
b = 323.234;
c = b/a;
printf(「the 13/2 = %f\n」, c);
printf(「hello world !\n」);
return 0;
}
1)使用arm-linux-gnueabihf-gcc編譯，使用「-v」選項以獲取更詳細的信息:
# arm-linux-gnueabihf-gcc -v mfloat.c
COLLECT_GCC_OPTIONS=』-v』 『-march=armv7-a』 『-mfloat-abi=hard』 『-mfpu=vfpv3-d16′ 『-mthumb』
-mfloat-abi=hard，可看出使用hard硬體浮點模式。
2)使用arm-linux-gnueabi-gcc編譯:
# arm-linux-gnueabi-gcc -v mfloat.c
COLLECT_GCC_OPTIONS=』-v』 『-march=armv7-a』 『-mfloat-abi=softfp』 『-mfpu=vfpv3-d16′ 『-mthumb』
-mfloat-abi=softfp，可看出使用softfp模式。
三. 拓展閱讀
下文闡述了ARM代碼編譯時的軟浮點(soft-float)和硬浮點(hard-float)的編譯以及鏈接實現時的不同。從VFP浮點單元的引入到軟浮點(soft-float)和硬浮點(hard-float)的概念
VFP (vector floating-point)
從ARMv5開始，就有可選的 Vector Floating Point (VFP) 模塊，當然最新的如 Cortex-A8, Cortex-A9 和 Cortex-A5 可以配置成不帶VFP的模式供晶元廠商選擇。
VFP經過若干年的發展，有VFPv2 (一些 ARM9 / ARM11)、 VFPv3-D16（只使用16個浮點寄存器，默認為32個）和VFPv3+NEON (如大多數的Cortex-A8晶元) 。對於包含NEON的ARM晶元，NEON一般和VFP公用寄存器。
硬浮點Hard-float
編譯器將代碼直接編譯成發射給硬體浮點協處理器（浮點運算單元FPU）去執行。FPU通常有一套額外的寄存器來完成浮點參數傳遞和運算。
使用實際的硬體浮點運算單元FPU當然會帶來性能的提升。因為往往一個浮點的函數調用需要幾個或者幾十個時鍾周期。
軟浮點 Soft-float
編譯器把浮點運算轉換成浮點運算的函數調用和庫函數調用，沒有FPU的指令調用，也沒有浮點寄存器的參數傳遞。浮點參數的傳遞也是通過ARM寄存器或者堆棧完成。
現在的Linux系統默認編譯選擇使用hard-float，即使系統沒有任何浮點處理器單元，這就會產生非法指令和異常。因而一般的系統鏡像都採用軟浮點以兼容沒有VFP的處理器。
armel ABI和armhf ABI
在armel中，關於浮點數計算的約定有三種。以gcc為例，對應的-mfloat-abi參數值有三個：soft,softfp,hard。
soft是指所有浮點運算全部在軟體層實現，效率當然不高，會存在不必要的浮點到整數、整數到浮點的轉換，只適合於早期沒有浮點計算單元的ARM處理器；
softfp是目前armel的默認設置，它將浮點計算交給FPU處理，但函數參數的傳遞使用通用的整型寄存器而不是FPU寄存器；
hard則使用FPU浮點寄存器將函數參數傳遞給FPU處理。
需要注意的是，在兼容性上，soft與後兩者是兼容的，但softfp和hard兩種模式不兼容。
默認情況下，armel使用softfp，因此將hard模式的armel單獨作為一個abi，稱之為armhf。
而使用hard模式，在每次浮點相關函數調用時，平均能節省20個CPU周期。對ARM這樣每個周期都很重要的體系結構來說，這樣的提升無疑是巨大的。
在完全不改變源碼和配置的情況下，在一些應用程序上，使用armhf能得到20%——25%的性能提升。對一些嚴重依賴於浮點運算的程序，更是可以達到300%的性能提升。
Soft-float和hard-float的編譯選項
在CodeSourcery gcc的編譯參數上，使用-mfloat-abi=name來指定浮點運算處理方式。-mfpu=name來指定浮點協處理的類型。
可選類型如fpa，fpe2，fpe3，maverick，vfp，vfpv3，vfpv3-fp16，vfpv3-d16，vfpv3-d16-fp16，vfpv3xd，vfpv3xd-fp16，neon，neon-fp16，vfpv4，vfpv4-d16，fpv4-sp-d16，neon-vfpv4等。
使用-mfloat-abi=hard (等價於-mhard-float) -mfpu=vfp來選擇編譯成硬浮點。使用-mfloat-abi=softfp就能兼容帶VFP的硬體以及soft-float的軟體實現，運行時的連接器ld.so會在執行浮點運算時對於運算單元的選擇，
是直接的硬體調用還是庫函數調用，是執行/lib還是/lib/vfp下的libm。-mfloat-abi=soft （等價於-msoft-float）直接調用軟浮點實現庫。
在ARM RVCT工具鏈下，定義fpu模式：
–fpu softvfp
–fpu softvfp+vfpv2
–fpu softvfp+vfpv3
–fpu softvfp+vfpv_fp16
–fpu softvfp+vfpv_d16
–fpu softvfp+vfpv_d16_fp16.
定義浮點運算類型
–fpmode ieee_full : 所有單精度float和雙精度double的精度都要和IEEE標准一致，具體的模式可以在運行時動態指定；
–fpmode ieee_fixed ： 舍入到最接近的實現的IEEE標准，不帶不精確的異常；
–fpmode ieee_no_fenv ：舍入到最接近的實現的IEEE標准，不帶異常；
–fpmode std ：非規格數flush到0、舍入到最接近的實現的IEEE標准，不帶異常；
–fpmode fast ： 更積極的優化，可能會有一點精度損失。
『伍』 riotboard 使用什麼交叉編譯工具鏈
不需要改源碼Makefile，只要在你的驅動目錄下配置好Makefile裡面的源碼樹路徑就行了。
obj-m := led_ko.o
KDIR := /home/zs5577517/ti-ezsdk_dm816x-evm_5_03_01_15/board-support/linux-2.6.37-psp04.00.01.13.patch2
all:
make -C $(KDIR) M=$(PWD) moles ARCH=arm CROSS_COMPILE=/home/zs5577517/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-
clean:
rm -f *.ko *.o
『陸』 Linux嵌入式交叉編譯工具鏈問題 淺談
交叉編譯工具鏈是一個由編譯器、連接器和解釋器組成的綜合開發環境，交叉編譯工具鏈主要由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
。
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來生成試驗箱上的程序了！