交叉編譯器的名字的命名規則
交叉編譯器的名字的命名規則
在折騰嵌入式開發，用到交叉編譯器的時候，常常會看到這樣的名字：
arm-xscale-linux-gnueabi-gcc
arm-liunx-gnu-gcc
等等
其中，對應的交叉編譯器的前綴為：
arm-xscale-linux-gnueabi-
arm-liunx-gnu-
而關於這些名字，我之前也是沒註意其具體含義，或者說對於其含義也是很模糊的感覺，不是很清楚這些名字是從何而來的。
後來，經過折騰了crosstool-ng後，基本上明白了這些名字，是如何生成的。
其中，貌似此交叉編譯器命名的規則，應該是通用的，至少記得是Buildroot中，好像也是這樣命名的。
下面，就以crosstool-ng為例，參考我之前折騰crosstool-ng期間：
【整理】crosstool中如何設置xscale的Tuple’s vendor string(CT_TARGET_VENDOR)
所了解到的內容，來解釋解釋，這些名字的含義。
3.1.1. 交叉編譯器名字舉例
此處，以編譯crosstool-ng中：
【記錄】重試使用最新版本1.18.0的crosstool-ng去配置和編譯xscale的交叉編譯器
通過ct-ng list-samples中得到的輸出為例，
當做交叉編譯器的名字的例子，供參考：
[email protected]~/develop/crosstool-ng/crosstool-ng-1.18.0_build $ ct-ng list-samples Status Sample name [G.X] alphaev56-unknown-linux-gnu [G.X] alphaev67-unknown-linux-gnu [G.X] arm-bare_newlib_cortex_m3_nommu-eabi [G.X] arm-cortex_a15-linux-gnueabi [G..] arm-cortex_a8-linux-gnueabi [G..] arm-davinci-linux-gnueabi [G..] armeb-unknown-eabi [G.X] armeb-unknown-linux-gnueabi [G.X] armeb-unknown-linux-uclibcgnueabi [G..] arm-unknown-eabi [G..] arm-unknown-linux-gnueabi [G.X] arm-unknown-linux-uclibcgnueabi [G.X] armv6-rpi-linux-gnueabi [G.X] avr32-unknown-none [G..] bfin-unknown-linux-uclibc [G..] i586-geode-linux-uclibc [G.X] i586-mingw32msvc,i686-none-linux-gnu [G.X] i686-nptl-linux-gnu [G.X] i686-unknown-mingw32 [G.X] m68k-unknown-elf [G.X] m68k-unknown-uclinux-uclibc [G.X] mips64el-n32-linux-uclibc [G.X] mips64el-n64-linux-uclibc [G.X] mips-ar2315-linux-gnu [G..] mipsel-sde-elf [G..] mipsel-unknown-linux-gnu [G.X] mips-malta-linux-gnu [G..] mips-unknown-elf [G.X] mips-unknown-linux-uclibc [G..] powerpc-405-linux-gnu [G.X] powerpc64-unknown-linux-gnu [G..] powerpc-860-linux-gnu [G.X] powerpc-e300c3-linux-gnu [G.X] powerpc-e500v2-linux-gnuspe [G..] powerpc-unknown_nofpu-linux-gnu [G..] powerpc-unknown-linux-gnu [G..] powerpc-unknown-linux-uclibc [G.X] s390-ibm-linux-gnu [G.X] s390x-ibm-linux-gnu [G..] sh4-unknown-linux-gnu [G..] x86_64-unknown-linux-gnu [G..] x86_64-unknown-linux-uclibc [G.X] x86_64-unknown-mingw32 L (Local) : sample was found in current directory G (Global) : sample was installed with crosstool-NG X (EXPERIMENTAL): sample may use EXPERIMENTAL features B (BROKEN) : sample is currently broken
3.1.2. crosstool-ng中交叉編譯前綴的命名規則
crosstool-ng中，交叉編譯器的（前綴）的名字的命名規則是：
arch-vendor-kernel-system
對應分別是：
3.1.2.1. 交叉編譯器名字中的arch部分
arch，即系統架構
表示交叉編譯器，是用於哪個目標系統架構中，用於那個平臺中的
即，用此交叉編譯器編譯出來的程序，是運行在哪種CPU上面的
arch的值，常見的有很多種，比如arm，x86，mips等等。
例 3.1. 舉例：交叉編譯器中的arch的值
arm-cortex_a8-linux-gnueabi中的arm
mips-ar2315-linux-gnu中的mips
powerpc-e500v2-linux-gnuspe中的powerpc
x86_64-unknown-mingw32中的x86_64
3.1.2.1.1. crosstool-ng中arch的值
crosstool-ng中，和arch對應的值，應該就是"Target options"中的"Target Architecture"的值了。
比如常見的，配置為arm的話，就是：
Target options
Target Architecture (arm) --->
對應的配置參數是：ARCH_arm
3.1.2.2. 交叉編譯器名字中的vendor部分
vendor，即生成廠家，提供商
表示誰提供的，即誰制作出來這個交叉編譯器的。
vendor的值，貌似是可以自己隨便填寫的。
其他常見寫法，還有寫成編譯交叉編譯器的作者的自己的名字的
比如，我叫crifan，那麽就可以寫成crifan，然後生成的交叉編譯器，就是xxx-crifan-xxx-xxx了。
更加通用的做法，好像是：
把vendor寫成，體系架構的值，比如我之前針對xscale的去配置crosstool-ng的時候，就寫了個xscale。
或者寫成CPU的廠家的名字，或者是開發板的名字等等。
例 3.2. 舉例：交叉編譯器中的vendor的值
- arm-cortex_a8-linux-gnueabi中的cortex_a8，就屬於CPU的名字
- mips-ar2315-linux-gnu中的ar2315
- powerpc-e500v2-linux-gnuspe中的e500v2，也是CPU的內核名
- arm-buildroot-linux-uclibcgnueabi中的buildroot，是之前折騰Buildroot時，看到的，即Buildroot把自己視為當前自己制作出來的交叉編譯器的vendor。
3.1.2.2.1. crosstool-ng中vendor的值
crosstool-ng中，和vendor對應的值，應該就是"Toolchain options"中的"Tuple‘s vendor string"的值了。
比如我之前配置為xscale的話，就是：
Toolchain options
(xscale) Tuple‘s vendor string
對應的配置參數是：CT_TARGET_VENDOR
對應的help的解釋是：
┌────────────────────────────────── Tuple‘s vendor string ──────────────────────────────────┐
│ CT_TARGET_VENDOR: │
│ │
│ Vendor part of the target tuple. │
│ │
│ A tuple is of the form arch-vendor-kernel-system. │
│ You can set the second part, vendor, to whatever you see fit. │
│ Use a single word, or use underscores "_" to separate words. │
│ Use neither dash nor space, as it breaks things. │
│ │
│ Keep the default (unknown) if you don‘t know better. │
│ │
│ Symbol: TARGET_VENDOR [=xscale] │
│ Type : string │
│ Prompt: Tuple‘s vendor string │
│ Defined at config/toolchain.in:99 │
│ Location: │
│ -> Toolchain options │
3.1.2.3. 交叉編譯器名字中的kernel部分
kernel，直譯為，內核
其實指的是，你用此交叉編譯器，編譯出來的程序，所運行的目標系統
即，此交叉編譯器，編譯出來的程序，在什麽系統中，什麽環境中，運行。
而對應的環境或系統，主要有兩種：
- Linux
表示：有OS（此處主要指的是Linux）操作系統的環境
比如，我用交叉編譯器，編譯一個helloworld程序，然後下載到嵌入式開發中的嵌入式Linux中運行，
就屬於，用此交叉編譯器，編譯出來的程序，是要運行於，帶OS，即嵌入式Linux系統，環境中的
此處，簡稱為，有OS的目標系統：Linux
- bare-metal
bare-metal，直譯為：裸金屬
表示：無（此處主要指的是Linux）操作系統的環境，
比如，用此交叉編譯器，去編譯一個Uboot，或者是其他一個小程序，是運行在，無嵌入式Linux的時候，單獨運行的一個程序。
比如，你購買的嵌入式系統開發版，常常附帶一些小程序，比如點亮LED，跑馬燈等程序，就是這種，運行在無OS的環境的
此處，簡稱為：無OS系統的：bare-metal
關於，運行在有OS的Linux下，和，無OS的bare-metal，到底有何區別
目前，還沒有完全搞懂。
但是，之前遇到一個實際的例子：
之前用比較新的一個交叉編譯器去編譯比較老的uboot時，會出現一個錯誤：
【已解決】uboot交叉編譯出錯：gcc/config/arm/lib1funcs.asm:1266: undefined reference to `raise’
其就是和這個kernel有關：
編譯的uboot，目標運行平臺，不是Linux，而是裸的開發板，即Linux還沒有運行呢，Uboot去運行，去初始化開發板的時候
詳細的情況，見該貼中的解釋。
例 3.3. 舉例：交叉編譯器中的kernel的值
- arm-bare_newlib_cortex_m3_nommu-eabi中的bare_newlib_cortex_m3_nommu，此處的bare，應該就是指的是bare-metal，用於運行在無OS的環境下
- powerpc-e300c3-linux-gnu中的linux
- m68k-unknown-uclinux-uclibc中的uclinux，就是指的是編譯出來的程序，是運行於沒有MMU的uclinux下
3.1.2.3.1. crosstool-ng中kernel的值
crosstool-ng中，和kernel對應的值，應該就是"Operating System"中的"Target OS"的值了。
比如我之前配置為Linux的話，就是：
Operating System
Target OS (linux) --->
對應的配置參數是：GEN_CHOICE_KERNEL中的CT_KERNEL_linux
對應的help的解釋是：
┌────────────────────────────────────────── linux ──────────────────────────────────────────┐
│ CT_KERNEL_linux: │
│ │
│ Build a toolchain targeting systems running Linux as a kernel. │
│ │
│ Symbol: KERNEL_linux [=y] │
│ Type : boolean │
│ Prompt: linux │
│ Defined at config.gen/kernel.in:8 │
│ Depends on: GEN_CHOICE_KERNEL [=y] && KERNEL_linux_AVAILABLE [=y] │
│ Location: │
│ -> Operating System │
│ -> Target OS (GEN_CHOICE_KERNEL [=y]) │
│ Selects: KERNEL_SUPPORTS_SHARED_LIBS [=y] │
3.1.2.4. 交叉編譯器名字中的system部分
system，直譯為，系統
其實主要表示的，交叉編譯器所選擇的庫函數和目標系統
最常見的一些值有，gnu，gnueabi，uclibcgnueabi等等。
其中，此處有幾方面的值，表示了幾方面的含義：
3.1.2.4.1. system中的gnu
好像都是gnu
不是很明白，貌似是：
gnu == gnu libc == glibc
即，gnu，就是表示用的是glibc的意思。
3.1.2.4.1.1. crosstool-ng中system為gnu的情況
crosstool-ng中，和system中gnu對應的值，應該就是"C-library"中的"C library"的值設置為"glibc"了。
C-library
C library (glibc) --->
對應的配置參數是：CT_LIBC_glibc
對應的help的解釋是：
┌────────────────────────────────────────── glibc ──────────────────────────────────────────┐
│ CT_LIBC_glibc: │
│ │
│ The de-facto standard for Linux distributions. │
│ Feature-rich, but large... Most usefull for desktop-like systems. │
│ │
│ Symbol: LIBC_glibc [=y] │
│ Type : boolean │
│ Prompt: glibc │
│ Defined at config.gen/libc.in:53 │
│ Depends on: GEN_CHOICE_LIBC [=y] && LIBC_glibc_AVAILABLE [=y] && !WINDOWS [=n] && !\ │
│ BARE_METAL [=n] && ARCH_USE_MMU [=y] │
│ Location: │
│ -> C-library │
│ -> C library (GEN_CHOICE_LIBC [=y]) │
│ Selects: LIBC_SUPPORT_NPTL [=y] && CC_CORE_PASSES_NEEDED [=y] │
3.1.2.4.2. system中的eabi
與此相對應的，之前早期的是oabi
eabi和oabi的對比，詳見：
［整理］EABI和OABI
3.1.2.4.2.1. crosstool-ng中system為eabi的情況
crosstool-ng中，和system中eabi對應的值，應該就是"Target options"中的"-*- Use EABI"的值了。
Target options
-*- Use EABI
註意：此處是選擇的ARM，EABI在此處，已經是默認，無法修改的值，只能是EABI了。
好像是因為，Linux內核等其他選擇導致的，此處無法更改EABI。
對應的配置參數是：CT_ARCH_ARM_EABI
對應的help的解釋是：
┌──────────────────────────────────────── Use EABI ─────────────────────────────────────────┐
│ CT_ARCH_ARM_EABI: │
│ │
│ Set up the toolchain so that it generates EABI-compliant binaries. │
│ │
│ If you say ‘n‘ here, then the toolchain will generate OABI binaries. │
│ OABI has long been deprecated, and is now considered legacy. │
│ │
│ Symbol: ARCH_ARM_EABI [=y] │
│ Type : boolean │
│ Prompt: Use EABI │
│ Defined at config/arch/arm.in.2:54 │
│ Depends on: ARCH_arm [=y] │
│ Location: │
│ -> Target options │
│ Selected by: ARCH_ARM_EABI_FORCE [=y] && ARCH_arm [=y] │
3.1.2.4.3. system中的uclibc
uclibc，是c庫中的一種
crosstool-ng中，目前支持三種：glibc,eglibc,uclibc
關於三種的關系，詳見：
【整理】uclibc,eglibc,glibc之間的區別和聯系
3.1.2.4.3.1. crosstool-ng中system為uclibc的情況
crosstool-ng中，和system中uclibc對應的值，應該就是"C-library"中的"C library"的值設置為"uClibc"了。
C-library
C library (uClibc) --->
對應的配置參數是：CT_LIBC_uClibc
對應的help的解釋是：
┌───────────────────────────────────────── uClibc ──────────────────────────────────────────┐
│ CT_LIBC_uClibc: │
│ │
│ The de-facto standard for embeded linux systems. │
│ │
│ Highly configurable, thus as feature-rich as you │
│ need, without compromising for size. │
│ │
│ Symbol: LIBC_uClibc [=y] │
│ Type : boolean │
│ Prompt: uClibc │
│ Defined at config.gen/libc.in:24 │
│ Depends on: GEN_CHOICE_LIBC [=y] && LIBC_uClibc_AVAILABLE [=y] && !WINDOWS [=n] && !\ │
│ BARE_METAL [=n] │
│ Location: │
│ -> C-library │
│ -> C library (GEN_CHOICE_LIBC [=y]) │
│ Selects: LIBC_SUPPORT_LINUXTHREADS [=y] && LIBC_SUPPORT_THREADS_NONE [=y] && \ │
│ CC_CORE_PASSES_NEEDED [=y] │
所以，針對上述，gnu，eabi，uclibc等幾個選項，對應的常見的一些組合的含義是：
- gnu
等價於：glibc+oabi
- gnueabi
等價於：glibc+eabi
- uclibc
等價於：uclibc+oabi（待確認）
例 3.4. 舉例：交叉編譯器中的system的值
- arm-cortex_a8-linux-gnueabi中的gnueabi，即glibc+eabi
- mips-ar2315-linux-gnu中的gnu，即glibc+oabi
- powerpc-e500v2-linux-gnuspe中的gnuspe，沒搞懂啥意思。。
- x86_64-unknown-mingw32中的mingw32，用的是Windows下的mingw32的庫
交叉編譯器的名字的命名規則