記一次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，終於成功
問題解決
看來關鍵並不在系統環境的兼容性上。
總結
-
這次的問題的出錯與解決給出了一個經驗：多去嘗試不同的解決方案而不是快速地否決自己的想法，這樣才能有利於挖掘出工作時潛在的注意事項以及發現最關鍵的錯誤。
-
還有就是，報錯信息只會反映局部錯誤，而我們需要做的是找出錯誤的來源，而大部分時候，報錯信息都不會和我們想要的結果看起來有關，所以如果報錯信息較為復雜而導致沒有頭緒，這是正常的，只有多去搜集類似經驗，才能最終對種種報錯信息明確在心。