记一次uboot编译/经验/教训

- 最近学习uboot移植有关的知识，在了解原理后自己编译uboot，但是出现了好多各式各样的错误，最后换了几次系统环境之后才找到错误来源

1.准备源码与交叉编译工具链

环境：ubuntu19.04虚拟机

首先从linux公社下载了2013.01版的uboot（uboot从多年前开始使用时间作为版本号）使用 tar xvf命令解压

注意：不要把解压后的文件夹放在windows共享文件夹下，因为windows下没有符号链接，会导致编译失败，必须把它复制到虚拟机自己的文件夹下。

而我这里在复制文件夹时出现了如下错误：

解决办法是直接复制压缩包，然后在复制后的目录解压

系统中要有gcc交叉编译器，我用的是5.4.0版本

如果是下载的编译之后打包的压缩包，则将压缩包解压，将解压后文件下的bin目录添加到环境变量PATH中：

export PATH=<bin的绝对路径>:$PATH

(尖括号不加)

当然我们应该把这句话添加到 ~/.bashrc里面，以便于之后再次开机不需要重新输入命令

2.配置编译

配置架构与编译器

进入uboot解压后的目录 sudo vi Makefile

在里面开头加上如下内容

ARCH=arm

CROSS_COMPILE=<bin的绝对路径>/arm-linux-none-linux-gnueabi-

(尖括号不加)

要注意的是，即使我们前面已经把交叉编译器添加进PATH了，但是这里如果不用绝对路径的话仍然可能会导致找不到编译器，所以添加绝对路径更加保险

编译mini2440目标程序

这里uboot有关于mini2440的配置，所以可以直接编译，在uboot目录下输入：

sudo make mini2440

遇到的困难/错误

一开始我的ubuntu19.04给出了如下错误信息

网上资料表明是64位机器与32位不兼容，需要apt安装32位有关的库libgl1-mesa-dri:i386

但我的ubuntu安装了后并未改善

之后我决定换32位系统————希望根治不兼容问题

于是安装了ubuntu16.04.6的i386版本虚拟机

重新做了一遍以上步骤之后，报错如下：

而且这两次都与offsets有关：

从报错来看，编译器出问题不是很可能，应该就是系统环境所造成的库的缺失，但是按照网上的办法安装了库也没有用，于是我想用我另外一个ubuntu16的系统来代替虚拟机试一试
不过在这之前我想到了windows自带的WSL，我的是ubuntu18.04LTS，于是顺便拿它试了一下

没想到目标文件被成功编译了出来

继续寻找原因

显然并没有根本解决问题

我又考虑到交叉编译工具在共享目录下，可能对运行有影响，所以将其拷贝到虚拟机目录下再运行，不过没有改变，但是在尝试中发现了这样的错误

fatal error: linux/compiler-gcc5.h: No such file or directory

经过搜索后，得知这是gcc版本太高的原因，所以将gcc降到了4.4.3

之后出现了以下错误

搜索得知，仍然是gcc版本过高的原因

考虑到gcc配置需要更多时间，于是我直接下载了2016版的uboot以适应当前版本的gcc，在ubuntu16虚拟机下解压，修改好Makefile之后，在超级用户权限下直接make，终于成功

问题解决

看来关键并不在系统环境的兼容性上。

总结

这次的问题的出错与解决给出了一个经验：多去尝试不同的解决方案而不是快速地否决自己的想法，这样才能有利于挖掘出工作时潜在的注意事项以及发现最关键的错误。
还有就是，报错信息只会反映局部错误，而我们需要做的是找出错误的来源，而大部分时候，报错信息都不会和我们想要的结果看起来有关，所以如果报错信息较为复杂而导致没有头绪，这是正常的，只有多去搜集类似经验，才能最终对种种报错信息明确在心。