解释什么是交叉编译之前，先要明白一个概念：本地编译我们之前常见的软件开发，都是属于本地编译：在当前的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.1.1. 已有的交叉工具链的下载

3.4.1.1.1. ELDK的下载

3.4.2. 使用已有交叉编译器的缺点

3.4.3. 自己手动编译交叉编译器的优点

3.4.4. 自己手动编译交叉编译器的缺点

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

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_PASS

Ta的文章更多 >>

交叉编译详解
0 个评论

交叉编译详解

交叉编译详解

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的情况

Ta的文章 更多 >>

热门文章

举报内容

检举类型

检举原因

检举说明(必填)

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

第 1 章交叉编译简介

第 2 章交叉工具链简介

第 3 章交叉编译器简介

Ta的文章更多 >>