buildroot之交叉编译环境

前言:

    为了搭建交叉编译环境，查了很多的方法，有自己搭建的(高手)，有的用cross-ng工具的等等，最后查到了buildroot这个工具，最后为啥选择这个工具的原因是buildroot不仅能搭建交叉编译环境，而且还能编译内核，根文件系统，可见功能的强大，但是第一次用这个工具还是出现各种各样的问题，所以这回要详细的说明buildroot搭建交叉编译器的使用方法并且解释出现的问题，虽然操作简化了很多，但是还是会出现很多的问题,废话不多说，进入主题

目标平台:

system type : Ralink MT7620A ver:2 eco:6
machine       : AWF-5G
processor     : 0
cpu model    : MIPS 24KEc V5.0
isa                : mips1 mips2 mips32r1 mips32r2

linux version : 3.10.44

buidRoot版本:

当然是最新版本 buildroot-2016.08.tar.gz, buildroot版本更新频率还是蛮高的，一般3个月一更新，因为我是在9月份研究这个buildroot,所以就用的这个版本，下载网址：

https://buildroot.org/download

具体操作:

1.将buildroot解压后,我们的第一步是创建默认配置, 首先查看一下目录下的list

buildroot为了方便用户使用, 提前配置好了很多平台的配置, 在configs文件夹里, 

我们发现有好多的配置信息，因为我们的目标平台是mip32的， 所以选择了qemu_mips32r2el_malta_defconfig这个配置, 细心的读者还会发现下面还有一个qemu_mips32r2的配置，区别是前者多了个“el”, 其实带el的意思是小端,因为我的目标平台是小端，所以选了这个配置

2. 在终端输入 make menuconfig 进一步配置,输入后会出现如下界面

因为我们的目的只是创建交叉编译环境，所以只用到了上面红色框框的选择项，他们的意义如下(尽可能大白话解释)

Target option:  选择目标平台, 大端小端等等, 目的是选择gcc的种类(编译出对应平台的可执行文件)

Buid options:   这个选项可厉害了,  里面有个选项可以配置编译后的交叉编译器的路径, 这个选项我吃了大亏, 在后面细说

ToolChain:  用于配置gcc所需要的版本，还有一些依赖的工具, 配置一个工具链,需要以下部分与工具

    ---Binutils : 编译链接需要的一些工具,比如ld,ar等

    ---Kernel headers：编译的c库需要与内核访问时, 需要头文件

    ---c/c++ libraries

    ---Gcc compiler

    ---GDB debugger(optional)

Target packages: 这个就不用说，太爽了,比如，想弄个sqlite移植到目标平台, 里面就有啦

3.接下来一个一个选项进去看一下

3.1 Target options

我们可以看到,我们一进到这个画面这些配置都被选好了，原因是因为之前我们已经配置好了默认选项，所以这样,  当然我们也可以自己重新选择

上面非常清楚明确, 目标平台是MIPS,小端, 最后use soft-float 选上

3.2 Build options

这个选项的话有一个地方要注意一下，就是Host dir, 其余选项都可忽略,  意思就是编译出的编译器的路径, 这个东西得特别注意一下，因为如果你的编译工具想在别的机器上用,最好填写一个共同的路径/usr/local

原因: 前提我已经编译好了工具链,所以我们看一下gcc的版本,

其中:   --with-sysroot=/usr/local/openWrt_cross/usr/mipsel-openwrt-linux-uclibc/ ：--with-sysroot选项的目的是告诉编译器在编译obj文件时所需要库的路径

COLLECT_GCC=/usr/local/openWrt_cross/usr/bin/mipsel-linux-gcc.br_real ：在gcc编译obj文件是会用到这个.br_real，我们看看这个.br_real里面的信息吧

我们可以看到 指定的library path: 是/usr/local/openwrt_cross/usr/lib

换句话说我们对HostDir进行了设置，指定的路径是/usr/loca/openwrt_cross(这个文件夹是手动自己创建的)/, 当对obj进行编译时,就会根据此路径去找相应的库

之前的出错现象:

我没有对host dir进行配置，所生成出的编译环境 会默认生成在路径/yy/xx/下--->所以对应的库路径信息是/yy/xx/usr/lib

生成好工具链后，在自己本地没问题, 当我把工具链打包放到别的PC上实验时,会出现mipsel-linux-gcc.br_real 找不到 libm.so的错误,原因是因为指定的库信息路径是/yy/xx/usr/lib，当然，在别人的PC上不会有/yy/xx的路径，所以出错

总结: 如果要实现工具链共享(就是放在别的机器上也能用) hostDir这个配置选项好配置好,我觉得一般就是/usr/local/就可以

引用手册的一句话:

You may want to compile, for your target, your own programs or other software that are not packaged in Buildroot. In order to
do this you can use the toolchain that was generated by Buildroot.
The toolchain generated by Buildroot is located by default in output/host/. The simplest way to use it is to add out
put/host/usr/bin/ to your PATH environment variable and then to use ARCH-linux-gcc, ARCH-linux-objdump,
ARCH-linux-ld, etc.
It is possible to relocate the toolchain - but then --sysroot must be passed every time the compiler is called to tell where the
libraries and header files are.
It is also possible to generate the Buildroot toolchain in a directory other than output/host by using the Build options
! Host dir option. This could be useful if the toolchain must be shared with other users.

3.3Tool chain

上面标号的都是这回我们用到的, 首先

①是选择工具链的种类 1. Buildroot toolchain: 内部工具链(因为这回要制作工具链,所以选择这个)  2. External toolchain: 外部工具链, 比如你已经有工具链了,想作文件系统, 就选外部工具链, 选上之后, 在之后的选项填写外部工具链的路径

②给编译后的工具链起个名字，这个随便起

③内核版本号, 这个比较重要, 要选你要运行目标平台内核版本相符合的版本号, 前面讲到，我的目标平台linux kernel 版本是 3.10.44, 所以这里选3.10.x的，当然，由于向下兼容,所以我也可以选3.10以下的版本都可以

之前出错的现象:

 默认配置选的是linux 4.x版本的头文件, 之后编译出工具链,用工具链生成的可执行文件在目标平台运行不了，因为目标平台的版本是3.10比较低, 所以这里要注意

引用手册上的话:

Change the version of the Linux kernel headers used to build the toolchain. This item deserves a few explanations. In the
process of building a cross-compilation toolchain, the C library is being built. This library provides the interface between
userspace applications and the Linux kernel. In order to know how to "talk" to the Linux kernel, the C library needs to have
access to the Linux kernel headers (i.e. the .h files from the kernel), which define the interface between userspace and the
kernel (system calls, data structures, etc.). Since this interface is backward compatible, the version of the Linux kernel headers
used to build your toolchain do not need to match exactly the version of the Linux kernel you intend to run on your embedded
system. They only need to have a version equal or older to the version of the Linux kernel you intend to run. If you use
kernel headers that are more recent than the Linux kernel you run on your embedded system, then the C library might be using
interfaces that are not provided by your Linux kernel.

④选择用到的c库,这里有3中选择,其中常用的是uClib,与gnuLib, uClib是嵌入gnuLib的缩减版本,它比较小(不是每个接口都实现, gunLib是都实现了,所以这个库比较大),而且现在都支持QT了所以一般大多嵌入式平台都用这个库,当然我的目标平台也是用的这个库

要注意的是： 当③④选了之后, ⑤⑥⑦会根据③④进行自动匹配版本,如果不是高手的话建议不要改,当然,作为新手的我尝试改了一下(把⑦中的版本降到了4.8而已，后来实验不成功又把⑥的版本也降了一下), 工具链编译出来了,编译出的hello world可执行文件可以在目标平台上运行,那么这就OK了吗？ 当然不是, 如果程序在写的复杂点,比如加了生成线程之类的程序就运行不起来了,所以建议③ ④选定后,⑤⑥⑦就不用在改了

手册其实也是这么说的

Note however that all packages in Buildroot are tested against the default uClibc configuration
bundled in Buildroot: if you deviate from this configuration by removing features from uClibc, some packages may no longer
build.

⑤ 这个选项是选uLibc专用的选项,在之前的buildroot中 这个选项有3个,

---linuxthreads

---linuxthreads (stable/old)

---Native POSIX Threading (NPTL)

老版本的linux 的线程库用的是linuxthreads，用着用着发现有很多不稳定的地方,于是就产生了 NPTL来代替 linuxthreads，所以随着linux的发展, linuxthreads被淘汰,

现在在当前的版本中干脆就没有了,直接就是NPTL了...

⑧ 这个一般也选上会生成g++, 还有Enable RPC support，是支持nfs

3.4Target packages

这个选项就不多说了，很吊, 以后想移植什么应用,直接去这里找就可以了,分分钟生成, 比如一些常用的嵌入式数据库啊 sql, sqlite redis 都可以轻松移植,选上即可

4.配置好之后,make即可, 等3-4个小时就搞定了(我的是50M电信宽带)

关于buildroot的研究就写到这里,之后做根文件系统什么的等用到了在说