解释什么是交叉编译之前，先要明白一个概念：本地编译我们之前常见的软件开发，都是属于本地编译：在当前的PC下，x86的CPU下，直接编译出来程序，可以运行的程序（或者库文件），其可以直接在当前的环境，即x86的CPU下，当前电脑中，运行。此时的编译，可以叫做，本地编译，即在当前目标平台下，编译出来的程序，也只是放到当前平台下，就可以运行的。交叉编译，是一个和，本地编译，相对应的概念。而所谓的，交叉编译，就是：在一种平台上编译，编译出来的程序，是放到别的平台上运行即编译的环境，和运行的环境，不一样，属于交叉的，此所谓cross 交叉编译，这个概念，主要和嵌入式开发有关。例 1.1. 在x86平台上编译，在ARM平台上运行一种最常见的例子就是：在进行嵌入式开发时手上有个嵌入式开发板，CPU是arm的然后在x86的平台下开发，比如Ubuntu的Linux，或者是Win7 然后就需要：在x86的平台上，（用交叉编译器）去编译你写好的程序代码编译生成的（可执行的）程序，是放到目标开发板，arm的CPU上运行的此所谓：在x86平台上编译，在ARM平台上运行
交叉编译，英文常写作cross compile，也有其他写法：crosscompile, cross compiling等

1.2. 为何要有交叉编译

之所以要有交叉编译，主要原因是：嵌入式系统中的资源太少具体的解释就是：交叉编译出来的程序，所要运行的目标环境中，各种资源，都相对有限，所以很难进行直接的本地编译最常见的情况是：在进行嵌入式开发时，目标平台，即嵌入式开发板，比如是最大主频200MHz的ARM的CPU，加上32M的RAM，加上1G的Nand Flash等等。在如此相对比较紧张的硬件资源的前提下，在已经运行了嵌入式Linux的前提下，是没法很方便的，直接在嵌入式Linux下，去本地编译，去在ARM的CPU下，编译出来，供ARM的CPU可以运行的程序的。因为编译，开发，都需要相对比较多的CPU，内存，硬盘等资源，而嵌入式开发上的那点资源，只够嵌入式（Linux）系统运行的，没太多剩余的资源，供你本地编译。 [提示]

BusyBox中包含make等和编译开发相关的工具对应的，等你后期熟悉了嵌入式开发，熟悉了Busybox后，比如在Buildroot中去配置Busybox，或者单独交叉编译BusyBox时：【记录】Ubuntu下为QEMU的arm平台交叉编译BusyBox 就会看到，后来的BusyBox，功能增加后，也已经包含了一些，和编译开发相关的工具，比如make等等而这些工具，本来的话，只是，放在PC端使用，即在x86平台下做开发的时候，在交叉编译的时候，才用到的工具，现在，也在（BusyBox的）嵌入式环境中，支持了。此时，如果，你在BusyBox中把相关的开发工具都选上的话，再加上，你的目标开发板的硬件配置足够强大的话，比如CPU都是以GHz为单位，等等加上相关的开发的库和工具都很全的话实际上，至少理论上，也是可以在你的嵌入式Linux中，进行，有限的，甚至是很大程度上的，本地开发即，直接在ARM的开发板上，嵌入式Linux中，直接进行嵌入式开发，进行针对ARM的本地编译比如，编译出一个helloworld，估计还是可以的这样，就不存在，或者说，避免了，此处所说的，交叉编译，而变成了本地编译就相当于，之前在x86的PC端的，编译程序放在x86的CPU上运行的本地编译，在ARM的CPU，嵌入式Linux中，也实现了但是很明显，对于更加复杂的程序或者库，在ARM开发板上直接编译的可行性和效率，相对就很低而且如果是本身折腾Uboot等东西，本身目标运行环境，就没有完整的（嵌入式Linux）系统的话，那么就更加没法在目标平台实现本地编译了。则还是只能进行，此处所说的，交叉编译

第 2 章交叉工具链简介

2.1. 什么是工具链
2.2. 什么是交叉工具链

搞懂了前面介绍的第 1 章 交叉编译简介的概念后，再来解释什么是交叉工具链。相关旧帖：【整理】关于Toolchain,cross toolchain,cross compiler

2.1. 什么是工具链

所谓的工具链，两部分的含义：

工具工具，即tool 工具，是用来干活的此处要干的活，目标是为了：生成（可以运行的）程序或库文件而为了达成此目标，内部的执行过程和逻辑主要包含了：
1. 编译编译的输入（对象）是：程序代码编译输出（目标）是：目标文件编译所需要的工具是：编译器编译器，常见的编译器，即为gcc
2. 链接链接的输入（对象）是：（程序运行时所依赖的，或者某个库所依赖的另外一个）库（文件）链接的输出（目标）是：程序的可执行文件，或者是可以被别人调用的完整的库文件链接所需要的工具是：链接器链接器，即ld
即，此处，为了将程序代码，编译成可执行文件，涉及到编译，链接（等其他步骤），要依赖到很多相关的工具，最核心的是编译器gcc，链接器ld。而此处，所谓的工具，主要指的就是：和程序编译链接等相关的gcc，ld等工具 binutils包含了ld等工具实际上，上面所说的ld，只是处理操作目标文件，二进制文件的最主要的一个工具而和操作目标等文件相关的，还有其他很多工具的：as，objcopy，strip，ar等等工具的所以，对此，GNU官网，弄出一个binutils，即binary utils，二进制工具（包），集成了这些，和操作二进制相关的工具集合，叫做binutils 所以，之后你所见到的，常见的工具，就是那个著名的GNU Binutils了。更加详细的解释，参见教程：GNU Binutils详解
链链，即链条，chain 之所以能称为链，你是说明不止一个东西，然后，按照对应的逻辑，串在一起，链在一起而对应的，涉及到的：
- 不止一个东西指的是就是前面所说的那个工具，即：和程序编译链接等相关的gcc，binutils等工具
- 按照对应的逻辑指的就是，按照程序本身编译链接的先后顺序，即：先编译，后链接，再进行后期其他的处理等等，比如用objcopy去操作相应的目标文件等等。

如此的，将：和程序编译链接等相关的gcc，binutils等工具按照先编译后链接等相关的编译程序的内在逻辑串起来，就成了我们所说的：工具链

2.2. 什么是交叉工具链

普通所说的，工具链，指的是当前自己的本地平台的工具链。用于，交叉编译，的工具链，就叫做交叉工具链即，那些工具，即编译的gcc，链接的ld，以及相关的工具，用于交叉编译的，工具链，叫做交叉工具链。交叉工具链，很明显，是用来，交叉编译，跨平台的程序所用的。交叉工具链，和（本地）工具链类似，也是包含了很多的，对应的工具，交叉编译版本的gcc，ld，as等等。但是，由于其中最最主要的是用于编译的gcc，所以，我们也常把：交叉工具链，简称为交叉编译器即：严格意义上来说，交叉编译器，只是指的是交叉编译版本的gcc 但是实际上为了叫法上的方便，我们常说的交叉编译器，都是指的是交叉工具链即，常说的交叉编译版本的gcc，比如arm-linux-gcc，实际上指代了，包含一系列交叉编译版本的交叉工具链（arm-linux-gcc，arm-linux-ld，arm-linux-as等等）而此文中，后面，所说的，如无特殊指明，均用交叉编译器指代交叉工具链。下面就对交叉编译器，进行详细的解释。

第 3 章交叉编译器简介

3.1. 交叉编译器的名字的命名规则

3.1.1. 交叉编译器名字举例

3.1.2. crosstool-ng中交叉编译前缀的命名规则

3.1.2.1. 交叉编译器名字中的arch部分

3.1.2.1.1. crosstool-ng中arch的值

3.1.2.2. 交叉编译器名字中的vendor部分

3.1.2.2.1. crosstool-ng中vendor的值

3.1.2.3. 交叉编译器名字中的kernel部分

3.1.2.3.1. crosstool-ng中kernel的值

3.1.2.4. 交叉编译器名字中的system部分

3.1.2.4.1. system中的gnu

3.1.2.4.1.1. crosstool-ng中system为gnu的情况

3.1.2.4.2. system中的eabi

3.1.2.4.2.1. crosstool-ng中system为eabi的情况

3.1.2.4.3. system中的uclibc

3.1.2.4.3.1. crosstool-ng中system为uclibc的情况

3.2. 如何得到交叉编译器

3.2.1. 拿来主义：直接去下载和使用别人已经编译好的交叉编译器

3.2.2. 自己动手，丰衣足食：自己去编译出来一套自己想要的交叉编译器

3.2.2.1. 白手起家从头开始制作交叉编译器
3.2.2.2. 借助别人的工具去制作交叉编译器

3.3. 各种制作交叉编译器的工具

3.3.1. crosstool-NG
3.3.2. Buildroot
3.3.3. crosstool
3.3.4. Embedded Linux Development Kit (ELDK)
3.3.5. OpenEmbedded的BitBake
3.3.6. Crossdev
3.3.7. OSELAS.Toolchain()

3.4. 使用已有的交叉编译器和自己手动编译交叉编译器之间的对比

3.4.1. 使用已有交叉编译器的优点
3.4.2. 使用已有交叉编译器的缺点
3.4.3. 自己手动编译交叉编译器的优点
3.4.4. 自己手动编译交叉编译器的缺点

相关旧帖：嵌入式开发之交叉编译器

3.1. 交叉编译器的名字的命名规则

在折腾嵌入式开发，用到交叉编译器的时候，常常会看到这样的名字： 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中得到的输出为例，当做交叉编译器的名字的例子，供参考： CLi@PC-CLI-1 ~/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] │

交叉编译详解

Crifan Li

前言

1. 本文目的

2. 待完成

第 1 章交叉编译简介

1.1. 什么是交叉编译

1.2. 为何要有交叉编译

第 2 章交叉工具链简介

2.1. 什么是工具链

2.2. 什么是交叉工具链

第 3 章交叉编译器简介

3.1. 交叉编译器的名字的命名规则

3.1.1. 交叉编译器名字举例

3.1.2. crosstool-ng中交叉编译前缀的命名规则

3.1.2.1. 交叉编译器名字中的arch部分

3.1.2.1.1. crosstool-ng中arch的值

3.1.2.2. 交叉编译器名字中的vendor部分

3.1.2.2.1. crosstool-ng中vendor的值

3.1.2.3. 交叉编译器名字中的kernel部分

3.1.2.3.1. crosstool-ng中kernel的值

3.1.2.4. 交叉编译器名字中的system部分

3.1.2.4.1. system中的gnu

3.1.2.4.1.1. crosstool-ng中system为gnu的情况

3.1.2.4.2. system中的eabi

3.1.2.4.2.1. crosstool-ng中system为eabi的情况

3.1.2.4.3. system中的uclibc

3.1.2.4.3.1. crosstool-ng中system为uclibc的情况

Ta的文章更多 >>

热门文章

交叉编译详解

Crifan Li

前言

1. 本文目的

2. 待完成

第 1 章 交叉编译简介

1.1. 什么是交叉编译

1.2. 为何要有交叉编译

第 2 章 交叉工具链简介

2.1. 什么是工具链

2.2. 什么是交叉工具链

第 3 章 交叉编译器简介

3.1. 交叉编译器的名字的命名规则

3.1.1. 交叉编译器名字举例

3.1.2. crosstool-ng中交叉编译前缀的命名规则

3.1.2.1. 交叉编译器名字中的arch部分

3.1.2.1.1. crosstool-ng中arch的值

3.1.2.2. 交叉编译器名字中的vendor部分

3.1.2.2.1. crosstool-ng中vendor的值

3.1.2.3. 交叉编译器名字中的kernel部分

3.1.2.3.1. crosstool-ng中kernel的值

3.1.2.4. 交叉编译器名字中的system部分

3.1.2.4.1. system中的gnu

3.1.2.4.1.1. crosstool-ng中system为gnu的情况

3.1.2.4.2. system中的eabi

3.1.2.4.2.1. crosstool-ng中system为eabi的情况

3.1.2.4.3. system中的uclibc

3.1.2.4.3.1. crosstool-ng中system为uclibc的情况

Ta的文章 更多 >>

热门文章

举报内容

检举类型

检举原因

检举说明(必填)

打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮

第 1 章交叉编译简介

第 2 章交叉工具链简介

第 3 章交叉编译器简介

Ta的文章更多 >>