我自認為一向是很不感冒Linux那些東東的，也不知道為什么，前兩天突然就心血來潮去搞一番LFS。于是很有紀念意義，特此記錄。

起先準備搞的是 LFS 6.1，因為只有 6.1 有官方中文手冊。但是我的宿主系統(tǒng)是 Arch Linux 2010.05，也許太新了，剛開始編譯 gcc 4.0.3 就過不了。后來就放棄了，換 6.7 的玩。

說到底這是件很無聊的事情。打過的最多的命令就是
tar -xzvf ...
tar -xvjf ...
./configure ...
make
make install
rm -rf ...

這么一套操作重復個百來下，加上無休止的等待，就成了。

以為成了，結(jié)果出狀況了：

似乎好像大概可能它找不到硬盤，而且我明明要 sda2 的，它卻找了 sdb2。

第一，在 8.4.2  grub-mkconfig -o /boot/grub/grub.cfg 的時候，grub的配置文件是利用它的命令自動生成的，結(jié)果它找錯了。可能是因為我一開始裝的時候拿塊硬盤是sdb，它就認sdb了。或者是之前那條命令 grub-install --grub-setup=/bin/true /dev/sda 我自作聰明地以為它要實際操作，把最后的sda換成了sdb的緣故吧。

第二是因為我在 VMWare 上跑，虛擬硬盤是 SCSI 的，編譯內(nèi)核之前沒配置對。后來看到了 http://www.cnblogs.com/benben7466/archive/2009/04/01/1427404.html，于是把 fusion mpt 中的全選上了（文章中的 Fusion MPT (base + ScsiHost) drivers 我沒找到，于是全選了= =），重新編譯內(nèi)核，啟動成功。

謹以此截圖留念：

流水賬結(jié)束了。正文開始。

我想談談對 LFS 中的工具鏈切換的理解。請允許我把 binutil 和 gcc 簡稱為編譯系統(tǒng)，把 glibc 簡稱為運行庫。用下面這張圖簡單表示一下：

首先，利用宿主系統(tǒng)的編譯系統(tǒng)編譯出一個依賴于宿主運行庫的新的編譯系統(tǒng)（Pass1），和獨立的新的運行庫（Pass1）。然后再利用運行在宿主運行庫上的新的編譯系統(tǒng)（Pass1）編譯出依賴于新的運行庫（Pass1）的新的編譯系統(tǒng)（Pass2）。這樣，產(chǎn)生了一個脫離宿主的編譯環(huán)境，利用這個編譯環(huán)境編譯出其他工具，一起作為臨時系統(tǒng)使用。

再在臨時系統(tǒng)中，編譯出目標系統(tǒng)中要用的運行庫（Pass2）和依賴于目標運行庫（Pass2）的編譯系統(tǒng)（Pass3）。目標系統(tǒng)中的編譯環(huán)境搭建完畢。最后使用這個編譯環(huán)境編譯出目標系統(tǒng)上的其他軟件。

不知道這個陳述有沒有問題？如果沒說錯的話，問題來了。其實，得到的臨時系統(tǒng)，已經(jīng)是一個不依賴于宿主的系統(tǒng)了，何不把這個作為 LFS 的目標系統(tǒng)呢？理由似乎只有“使它更純凈”之類的了。如果追求純凈，多搞一遍是不夠的，還是不純凈的；既然反正不純凈，為啥多做一遍呢？

由此，我想到了挺久以前我一直壓抑在心里的問題：同一個環(huán)境下的編譯器的升級問題。加入已經(jīng)有了 1.0 版的編譯器執(zhí)行文件和 2.0 版的編譯器源代碼，要如何產(chǎn)生 2.0 版的編譯器的執(zhí)行文件呢？是拿 1.0 版的去編譯 2.0 的源代碼，然后直接發(fā)布？還是再用新的 2.0 版的編譯器再編譯一遍（兩遍、三遍）？6.1 版的 LFS 手冊部分解決了這個疑問，它提到了在 gcc pass1 的時候做 bootstrap，即編譯一次后用產(chǎn)生的新編譯器編譯第二遍，再用產(chǎn)生的新的編譯器編譯第三遍，比較第二遍與第三遍結(jié)果是否相同。（LFS 6.7無此要求。）不知道這里的相同是指逐字節(jié)相同嗎？如果是，這在理論上可能嗎？我的想法是，已有的1.0版可能存在一個固有問題（或者不稱為問題，叫“特征”吧），它可能將影響到后面的一切，2.0 的編譯器不管自舉幾遍，或許總是無法完全消滅來自 1.0 的某些影響？

不知道現(xiàn)在理論上是怎樣回答這個問題的。工程上又是如何對待這個問題的呢？

這也許是個比較深層次的問題。抑或只是一個很膚淺的問題，只是我心生執(zhí)念罷了。期待解惑 ~_~