# 6.12\. GCC-4.0.3 GCC 軟件包包含 GNU 編譯器，其中有 C 和 C++ 編譯器。 **預計編譯時間：** 22 SBU (含測試套件)**所需磁盤空間：** 566 MB (含測試套件) ## 6.12.1\. 安裝 GCC 使用一個 `sed` 命令來禁止 GCC 安裝它自己的 `libiberty.a` 。我們將使用 Binutils 附帶的 `libiberty.a` 來代替： ``` sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in ``` 在[節 5.4, "GCC-4.0.3 - 第一遍"](../chapter05/gcc-pass1.html "5.4\. GCC-4.0.3 - 第一遍") 中應用的 bootstrap 編譯中，編譯器會有 `-fomit-frame-pointer` 的標志。非bootstrap編譯默認是忽略這個標志的，可以應用下面的`sed` 命令來確保編譯的可靠性。 ``` sed -i 's/^XCFLAGS =$/& -fomit-frame-pointer/' gcc/Makefile.in ``` `fixincludes` 腳本偶爾會因為修改系統的頭文件而出錯。因為GCC-4.0.3 和 Glibc-2.3.6 是不需要修改的，運行下面的命令可以避免 `fixincludes` 腳本運行： ``` sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in ``` GCC 中提供了一個 `gccbug` 腳本，會在編譯時偵測 mktemp 是否存在，并且在測試中加強代碼。這將會導致腳本使用一些不算很隨機的名字來命名臨時文件。因為我們后面會安裝 mktemp ，這里我們就模仿它的存在： ``` sed -i 's/@have_mktemp_command@/yes/' gcc/gccbug.in ``` GCC 的安裝指南推薦用一個新建的目錄來編譯它，而不是在源碼目錄中： ``` mkdir -v ../gcc-build cd ../gcc-build ``` 為編譯 GCC 做準備： ``` ../gcc-4.0.3/configure --prefix=/usr \ --libexecdir=/usr/lib --enable-shared \ --enable-threads=posix --enable-__cxa_atexit \ --enable-clocale=gnu --enable-languages=c,c++ ``` 編譯軟件包： ``` make ``` ### 重要 本節的GCC測試套件很重要。在任何情況下都不要省略這一步。 運行測試套件，但遇到錯誤不停止(你還記得那些老是出錯的測試吧)： ``` make -k check ``` 要查看測試單元的測試結果，可以運行： ``` ../gcc-4.0.3/contrib/test_summary ``` 如果只想看概要，可以把輸出通過管道傳遞給 **`grep -A7 Summ`** 。 結果可以跟 [_http://www.linuxfromscratch.org/lfs/build-logs/6.2/_](http://www.linuxfromscratch.org/lfs/build-logs/6.2/) 的進行比較。 一些預想不到的錯誤總是無法避免的。雖然GCC的開發者經常留意這些問題，但是有些還是沒有得到解決。通常，`libmudflap` 測試尤其被認為是有問題的（這是一個bug，參見[_http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003_](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003)）。 除非測試結果給上面URL的有很多不同，一般是可以安全繼續的。 安裝軟件包： ``` make install ``` 有的軟件包希望 C PreProcessor(預處理器)安裝在 `/lib` 目錄下，為了滿足它們的要求，我們創建如下符號鏈接： ``` ln -sv ../usr/bin/cpp /lib ``` 許多軟件包使用 `cc` 作為 C 編譯器的名字，為了滿足它們的要求，創建如下符號鏈接： ``` ln -sv gcc /usr/bin/cc ``` 現在，我們的最終工具鏈已經形成了，我們需要做的就是確保編譯、鏈接按照我們希望的完成。我們可以通過本章前面的簡冊方法來實現： ``` echo 'main(){}' > dummy.c cc dummy.c -Wl,--verbose &> dummy.log readelf -l a.out | grep ': /lib' ``` 如果所有的都工作正常，就不會有錯誤，并且命令的輸出應該是（允許不同平臺的動態鏈接器的名稱不同）： ``` [Requesting program interpreter: /lib/ld-linux.so.2] ``` 現在確保我們使用正確的 startfiles： ``` grep -o '/usr/lib.*/crt[1in].* .*' dummy.log ``` 如果所有的都工作正常，就不會有錯誤，并且命令的輸出應該是： ``` /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crt1.o succeeded /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crti.o succeeded /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crtn.o succeeded ``` 接下來，確認新的鏈接器被應用到了正確的搜索路徑中： ``` grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' ``` 如果所有的都工作正常，就不會有錯誤，并且命令的輸出應該是： ``` SEARCH_DIR("/usr/i686-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib") SEARCH_DIR("/usr/lib"); ``` 現在，確保我們正在使用正確的 libc ： ``` grep "/lib/libc.so.6 " dummy.log ``` 如果所有的都工作正常，就不會有錯誤，并且命令的輸出應該是 ``` attempt to open /lib/libc.so.6 succeeded ``` 最后，確保 GCC 正在使用正確的動態鏈接器： ``` grep found dummy.log ``` 如果所有的都工作正常，就不會有錯誤，并且命令的輸出應該是（允許不同平臺的動態鏈接器的名稱不同）： ``` found ld-linux.so.2 at /lib/ld-linux.so.2 ``` 如果輸出不是像上面那樣或者根本沒有輸出，那么就有大問題了。返回并檢查前面的操作，找出問題，并改正過來。最有可能的原因是上面修正 specs 文件時出錯。任何一個問題都需要在繼續之前解決掉。 一旦工具都工作正常，清理測試文件： ``` rm -v dummy.c a.out dummy.log ``` ## 6.12.2\. GCC 的內容 **安裝的程序：** c++, cc(→gcc), cpp, g++, gcc, gccbug, gcov**安裝的庫：** libgcc.a, libgcc_eh.a, libgcc_s.so, libstdc++.{a,so}, libsupc++.a ### 簡要描述 | | | | --- | --- | | `cc` | C 編譯器 | | `cpp` | C 預處理器。編譯器用它來將 #include 和 #define 這類聲明在源文件中展開。 | | `c++` | C++ 編譯器 | | `g++` | C++ 編譯器 | | `gcc` | C 編譯器 | | `gccbug` | 一個shell腳本，幫助創建有價值的 bug 報告。 | | `gcov` | 覆蓋測試工具，用來分析在程序的哪里做優化的效果最好。 | | `libgcc` | `gcc` 的運行時庫 | | `libstdc++` | 準 C++ 庫，包含許多常用的函數。 | | `libsupc++` | 為 C++ 語言提供支持的庫函數。 |