『壹』 在哪裡可以找到C語言標准庫的實現源代碼
linux下的glic庫的源碼鏈接：
http://ftp.gnu.org/gnu/glibc/，你可以下載最新版本的glibc-2.24.tar.gz這個壓縮文件，在Windows系統下直接用WinRAR解壓即可，如果在Linux系統下用命令行解壓的話，命令如下：tar -xzvf glibc-2.24.tar.gz。
『貳』 如何解決源碼包安裝時的依賴性問題
動態可執行文件使用最初編譯和鏈接程序時使用的庫文件的共享對象名稱來查找共享對象。它們在少數的幾個標准位置查找，比如在/lib和/usr/lib目錄及在LD_LIBRARY_PATH環境變數（主要用於指定查找共享庫，比如我們在安裝Oracle時指定路徑，exportLD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib:/usr/local/lib）指定的目錄中。順便提一下，在這些庫目錄中找到的共享對象可能不是真正的文件;它們可能是指向位於其他位置的真實庫文件的符號鏈接（但通常仍舊在標准庫目錄的一個目錄中）。至少從系統管理員的觀點是在用於創建共享庫文件的共享庫軟體包的名稱和共享庫文件的名稱之間通常沒有什麼關系。例如，GLIBC2.3軟體包用於創建libc.so.6共享庫文件。也從本示例中注意到，添加到共享庫文件名結束的版本號(.6)跟用於創建它的版本號(2.3)沒有關系。這是由共享庫軟體包開發人員有意完成的，以便GLIBC的新版本可以重用相同的共享庫文件名libc.so.6。這允許您在系統上載入新版本的GLIBC，而不用中斷動態鏈接到lib.so.6共享庫文件的所有程序，當然假定新版本的GLIBC向後與動態可執行文件最初所鏈接的老版本GLIBC兼容。因此，即使庫文件或共享對象文件有與它們相關的版本號，這些版本號也不能幫助你確定他們來自哪個版本的共享軟體包。
注意：當將whatprovides選項用於rpm查詢命令時，可以獲得有關使用rpm軟體包載入到系統的現有共享對象的信息。這種混亂是由下面的事實造成的：單個共享庫文件可能支持某個范圍的共享庫軟體包版本。例如，要檢查soname庫文件/lib/libc.so.6支持的GLIBC共享庫軟體包，運行下面的命令：
#objmp--all-headers/lib/libc.so.6|less
向下滾動此報告，直到到達Versiondefinitions:部分，以便查看libc.so.6共享庫文件支持哪些GLIBC版本：
Versiondefinitions:
10x010x0865f4e6libc.so.6
20x000x0d696910GLIBC_2.0
30x000x0d696911GLIBC_2.1
GLIBC_2.0
40x000x09691f71GLIBC_2.1.1
GLIBC_2.1
50x000x09691f72GLIBC_2.1.2
GLIBC_2.1.1
60x000x09691f73GLIBC_2.1.3
GLIBC_2.1.2
70x000x0d696912GLIBC_2.2
GLIBC_2.1.3
80x000x09691a71GLIBC_2.2.1
GLIBC_2.2
90x000x09691a72GLIBC_2.2.2
GLIBC_2.2.1
100x000x09691a73GLIBC_2.2.3
GLIBC_2.2.2
110x000x09691a74GLIBC_2.2.4
GLIBC_2.2.3
120x000x09691a76GLIBC_2.2.6
GLIBC_2.2.4
130x000x0d696913GLIBC_2.3
GLIBC_2.2.6
140x000x09691972GLIBC_2.3.2
GLIBC_2.3
150x000x09691973GLIBC_2.3.3
GLIBC_2.3.2
160x000x09691974GLIBC_2.3.4
GLIBC_2.3.3
170x000x0d696914GLIBC_2.4
GLIBC_2.3.4
180x000x0d696915GLIBC_2.5
GLIBC_2.4
190x000x0963cf85GLIBC_PRIVATE
GLIBC_2.5
200x000x0b792650GCC_3.0
在本示例中，1ibc.so.6共享庫文件支持原先為GLIBC版本2.0到2.5而開發的所有動態執行文件。注意：也可以使用objmp命令來從共享庫文件中提取soname，命令如下所示：
#objmp--all-headers/lib/libcrypto.so.0.9.8b|grepSONAME
SONAMElibcrypto.so.6
objmp:/lib/libcrypto.so.0.9.8b:
接下來，將討論rpm軟體包是如何生成的，以便在新系統上安裝rpm軟體包時，這些共庫依賴性是己知的。
三、Rpm軟體包和共享庫依賴性
當程序員生成rpm軟體包時，ldd命令用於報告動態可執行文件軟體包中所有動態可執行文件使用的所有共享庫。另一個混亂是由下面的事實帶來的：相同軟體包中的不同動態可執行文件可能與相同的共享庫軟體包的不同版本進行鏈接。例如，Heartbeat軟體包中的不同程序可能已經進行了開發，並動態鏈接到libc.so.6sonmae共享庫文件的不同GLIBC版本。對rpm命令使用-q和--requires參數，可以看到rpm軟體包需要的共享庫的完整清單。例如，要看到Heartbeatrpm軟體包所有的所需依賴性，請使用命令：
#rpm-q--requires-pheartbeat-1.x.x.i386.rpm
這產生了下面的報告：
sysklogd
/bin/sh
/bin/sh
/usr/bin/python
ld-linux.so.2
libapphb.so.0
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libccmclient.so.0
libdl.so.2
libglib-1.2.so.0
libhbclient.so.0
libpils.so.0
libplumb.so.0
libpthread.so.0
librt.so.1
libstonith.so.0
注意，在此報告中，libc.so.6soname是所需要的，此共享庫必須支持使用GLIBC共享軟體包版本號2.0、2.1、2.1.3、2.2和2.3進行鏈接的動態可執行文件。這是由下面的事實決定的：Heartbeat軟體包中的不同動態可執行文件是針對不同版本的libc.so.6庫的每個版本進行鏈接的。在了解了動態可執行文件、共享對象、soname和共享庫軟體包彼此是如何相關的後，下面准備來看這樣的一個例子：當嘗試安裝rpm軟體包，並且它由於依賴性錯誤而失敗時，會發生什麼。yum能夠從指定的伺服器自動下載RPM包並且安裝，可以自動處理依賴性關系，並且一次安裝所有依賴的軟體包，無須繁瑣地一次次下載、安裝。
四、手工解決依賴性問題
通常，當嘗試安裝發行版中沒有包括的軟體包（及不能由像up2date、apt-get或Yum一樣的更新工具自動解決其依賴性的軟體包）時，將碰到rpm依賴性錯誤。例如，如果嘗試在老的Linux發行版上使用rpm–ivh*rpm命令，例如所有的Heartbeatrpm包，那麼在安裝過程中就可能碰到下面的錯誤：
error:faileddependencies:
libc.so.6(GLIBC_2.3)isneededbyheartbeat-1.x.x
libc.so.6(GLIBC_2.3)isneededbyheartbeat-pils-1.x.x
libcrypto.so.0.9.6isneededbyheartbeat-stonith-1.x.x
libsnmp-0.4.2.6.soisneededbyheartbeat-stonith-1.x.x
注意，rpm命令沒有干擾報告所需的每個GLIBC共享庫軟體包版本號——它只報告所需的最高編號的版本號(GLIBC_2.3)。(假定原來的軟體包開發人員不會將相同軟體包中的可執行文件鏈接到不兼容版本的共享庫軟體包)所有的這些故障都報告所需的共享庫名稱或soname（而不是文件名稱，soname始終以「lib」開始）。但可以刪除添加到rpm報告的soname結束的版本號，並快速檢查以查看是否在系統中使用locate命令安裝這些共享庫(假設您的locate資料庫是最新的，有關更多信息，請參閱locate或slocate的手冊頁)。例如，
『叄』 linux下如何編譯源碼包或者說是安裝
1、安裝編碼源碼的編譯工具，一般是需要安裝gcc
yum install gcc
2、把源碼解壓
tar zxvf uname.tar.gz
3、進入解壓的目錄執行
./configure
make
make install
完成編譯安裝
『肆』 怎麼在CentOS里用yum升級glibc到2.1.3+版本
你好，
yum update glibc 可以將glibc升級到163倉庫中gblic最高的版本，不過一般yum倉庫里不會是最新。如果要安裝最新的，還是去官網上下載rpm包或者源碼包來安裝。
『伍』 如何解決源碼包安裝時的依賴性問題
動態可執行文件使用最初編譯和鏈接程序時使用的庫文件的共享對象名稱來查找共享對象。它們在少數的幾個標准位置查找，比如在/lib和/usr/lib目錄及在LD_LIBRARY_PATH環境變數（主要用於指定查找共享庫，比如我們在安裝Oracle時指定路徑，exportLD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib:/usr/local/lib）指定的目錄中。順便提一下，在這些庫目錄中找到的共享對象可能不是真正的文件;它們可能是指向位於其他位置的真實庫文件的符號鏈接（但通常仍舊在標准庫目錄的一個目錄中）。至少從系統管理員的觀點是在用於創建共享庫文件的共享庫軟體包的名稱和共享庫文件的名稱之間通常沒有什麼關系。例如，GLIBC2.3軟體包用於創建libc.so.6共享庫文件。也從本示例中注意到，添加到共享庫文件名結束的版本號(.6)跟用於創建它的版本號(2.3)沒有關系。這是由共享庫軟體包開發人員有意完成的，以便GLIBC的新版本可以重用相同的共享庫文件名libc.so.6。這允許您在系統上載入新版本的GLIBC，而不用中斷動態鏈接到lib.so.6共享庫文件的所有程序，當然假定新版本的GLIBC向後與動態可執行文件最初所鏈接的老版本GLIBC兼容。因此，即使庫文件或共享對象文件有與它們相關的版本號，這些版本號也不能幫助你確定他們來自哪個版本的共享軟體包。
注意：當將whatprovides選項用於rpm查詢命令時，可以獲得有關使用rpm軟體包載入到系統的現有共享對象的信息。這種混亂是由下面的事實造成的：單個共享庫文件可能支持某個范圍的共享庫軟體包版本。例如，要檢查soname庫文件/lib/libc.so.6支持的GLIBC共享庫軟體包，運行下面的命令：
#objmp--all-headers/lib/libc.so.6|less
向下滾動此報告，直到到達Versiondefinitions:部分，以便查看libc.so.6共享庫文件支持哪些GLIBC版本：
Versiondefinitions:
10x010x0865f4e6libc.so.6
20x000x0d696910GLIBC_2.0
30x000x0d696911GLIBC_2.1
GLIBC_2.0
40x000x09691f71GLIBC_2.1.1
GLIBC_2.1
50x000x09691f72GLIBC_2.1.2
GLIBC_2.1.1
60x000x09691f73GLIBC_2.1.3
GLIBC_2.1.2
70x000x0d696912GLIBC_2.2
GLIBC_2.1.3
80x000x09691a71GLIBC_2.2.1
GLIBC_2.2
90x000x09691a72GLIBC_2.2.2
GLIBC_2.2.1
100x000x09691a73GLIBC_2.2.3
GLIBC_2.2.2
110x000x09691a74GLIBC_2.2.4
GLIBC_2.2.3
120x000x09691a76GLIBC_2.2.6
GLIBC_2.2.4
130x000x0d696913GLIBC_2.3
GLIBC_2.2.6
140x000x09691972GLIBC_2.3.2
GLIBC_2.3
150x000x09691973GLIBC_2.3.3
GLIBC_2.3.2
160x000x09691974GLIBC_2.3.4
GLIBC_2.3.3
170x000x0d696914GLIBC_2.4
GLIBC_2.3.4
180x000x0d696915GLIBC_2.5
GLIBC_2.4
190x000x0963cf85GLIBC_PRIVATE
GLIBC_2.5
200x000x0b792650GCC_3.0
在本示例中，1ibc.so.6共享庫文件支持原先為GLIBC版本2.0到2.5而開發的所有動態執行文件。注意：也可以使用objmp命令來從共享庫文件中提取soname，命令如下所示：
#objmp--all-headers/lib/libcrypto.so.0.9.8b|grepSONAME
SONAMElibcrypto.so.6
objmp:/lib/libcrypto.so.0.9.8b:
接下來，將討論rpm軟體包是如何生成的，以便在新系統上安裝rpm軟體包時，這些共庫依賴性是己知的。
三、Rpm軟體包和共享庫依賴性
當程序員生成rpm軟體包時，ldd命令用於報告動態可執行文件軟體包中所有動態可執行文件使用的所有共享庫。另一個混亂是由下面的事實帶來的：相同軟體包中的不同動態可執行文件可能與相同的共享庫軟體包的不同版本進行鏈接。例如，Heartbeat軟體包中的不同程序可能已經進行了開發，並動態鏈接到libc.so.6sonmae共享庫文件的不同GLIBC版本。對rpm命令使用-q和--requires參數，可以看到rpm軟體包需要的共享庫的完整清單。例如，要看到Heartbeatrpm軟體包所有的所需依賴性，請使用命令：
#rpm-q--requires-pheartbeat-1.x.x.i386.rpm
這產生了下面的報告：
sysklogd
/bin/sh
/bin/sh
/usr/bin/python
ld-linux.so.2
libapphb.so.0
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libccmclient.so.0
libdl.so.2
libglib-1.2.so.0
libhbclient.so.0
libpils.so.0
libplumb.so.0
libpthread.so.0
librt.so.1
libstonith.so.0
注意，在此報告中，libc.so.6soname是所需要的，此共享庫必須支持使用GLIBC共享軟體包版本號2.0、2.1、2.1.3、2.2和2.3進行鏈接的動態可執行文件。這是由下面的事實決定的：Heartbeat軟體包中的不同動態可執行文件是針對不同版本的libc.so.6庫的每個版本進行鏈接的。在了解了動態可執行文件、共享對象、soname和共享庫軟體包彼此是如何相關的後，下面准備來看這樣的一個例子：當嘗試安裝rpm軟體包，並且它由於依賴性錯誤而失敗時，會發生什麼。yum能夠從指定的伺服器自動下載RPM包並且安裝，可以自動處理依賴性關系，並且一次安裝所有依賴的軟體包，無須繁瑣地一次次下載、安裝。
四、手工解決依賴性問題
通常，當嘗試安裝發行版中沒有包括的軟體包（及不能由像up2date、apt-get或Yum一樣的更新工具自動解決其依賴性的軟體包）時，將碰到rpm依賴性錯誤。例如，如果嘗試在老的Linux發行版上使用rpm–ivh*rpm命令，例如所有的Heartbeatrpm包，那麼在安裝過程中就可能碰到下面的錯誤：
error:faileddependencies:
libc.so.6(GLIBC_2.3)isneededbyheartbeat-1.x.x
libc.so.6(GLIBC_2.3)isneededbyheartbeat-pils-1.x.x
libcrypto.so.0.9.6isneededbyheartbeat-stonith-1.x.x
libsnmp-0.4.2.6.soisneededbyheartbeat-stonith-1.x.x
注意，rpm命令沒有干擾報告所需的每個GLIBC共享庫軟體包版本號——它只報告所需的最高編號的版本號(GLIBC_2.3)。(假定原來的軟體包開發人員不會將相同軟體包中的可執行文件鏈接到不兼容版本的共享庫軟體包)所有的這些故障都報告所需的共享庫名稱或soname（而不是文件名稱，soname始終以「lib」開始）。但可以刪除添加到rpm報告的soname結束的版本號，並快速檢查以查看是否在系統中使用locate命令安裝這些共享庫(假設您的locate資料庫是最新的，有關更多信息，請參閱locate或slocate的手冊頁)。例如，
『陸』 在Linux系統下使用hping3工具進行發包測試，網上下的都是源碼包裝不上，有RPM包或者源碼包的安裝方法嗎
源碼包要編譯，編譯前先閱讀源碼包的README和ISTALL文件 。裡面有詳細的編譯指南和包信賴關系，一般編譯軟體都是
# ./configure ［-option ］(option可選，是指編譯的配置選項，Readme里有詳細的說明）
# make
# make istall
『柒』 linux初學者問一個glibc的源代碼。
應該是宏定義吧，因為它不是一個語句，而是直接一行代碼。。另外，你可以閱讀一下。。
sysdeps/unix/make-syscalls.sh
sysdeps/unix/syscalls.list（sysdeps/unix/inet/syscalls.list）
sysdeps/unix/syscall-template.S
syscall-template.S顧名思義是個定義的模板，每個生成的系統調用都要參考這個模板，但是怎麼用模板來「刻畫」每一個系統調用呢？於是就有了syscalls.list，而make-syscalls.sh就是用模板和那個列表來構建生成系統調用定義的makefile，該makefile最終生成最後的定義。有興趣的朋友應該仔細看看這幾個文件。
現在再想想，這么做其實是有道理的，在Linux下，系統調用的真正定義有很多相似的地方，確實可以通過「模板」來生成對應的匯編，但是否真值得花時間去構建那麼抽象的一個模板和框架？我說不清楚，本著「懶惰」的原則確實應該如此，不過看看模板本身似乎原因不僅僅是「懶惰」。
從這里我們也可以看出glibc的代碼難讀啊，比起Linux內核來，不僅僅是風格的問題，還有就是使用了太多的tricks，導致的結果也很顯而易見，參與glibc開發的和參與linux內核開發的人明顯不是一個數量級的。
另外讀glibc 建議 參考 c函數庫 源碼剖析 （一本電子書 網上找一下） 有具體的實現。。
『捌』 linux 怎麼用glibc查看c源代碼
GNU C庫（glibc）是標准C庫的GNU實現。glibc是GNU工具鏈的關鍵組件，用於和二進制工具和編譯器一起使用，為目標架構生成用戶空間應用程序。
『玖』 在哪裡可以找到C語言標准庫的實現源代碼
http://www.gnu.org/software/libc/
如果網頁嫌麻煩，可以先裝git，然後
git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout --track -b glibc-2_11-branch origin/release/2.11/master
其實完全沒有必要全都看，無論你有沒有這個能力。因為由於歷史兼容等問題，C標准庫的代碼並不是很適合學習，裡面有些很雜亂。不過看過肯定比沒看好，畢竟都是牛人寫的。
望採納，謝謝
『拾』 如何安裝 glibc-2.15.tar
編譯步驟：
下載glibc-2.15.tar.gz和補丁包glibc-ports-2.15.tar.gz
解壓
$mv glibc-ports-2.15 glibc-2.15/ports
$mkdir glibc-build-2.15 &&cd glibc-build-2.15
$ ../glibc-2.15/configure \
--prefix=/usr/local/glibc_mips \
CC=mipsel-linux-gcc \
--host=mipsel-linux \
--build=i686-pc-linux-gnu \
--enable-add-on=nptl \
libc_cv_forced_unwind=yes \
libc_cv_c_cleanup=yes \
libc_cv_mips_tls=yes \
libc_cv_gnu99_inline=yes
ok,沒問題
$make &&make install
大功告成
##########################################################################
下面是我編譯時的過程和遇到的問題及解決：
##########################################################################
$tar xvf glibc-2.16.0.tar.bz2
$cd glibc-2.16.0
$./configure --prefix=/usr/local/glibc //先不加其他選項，除了安裝路徑，一切默認，網上一般配置arm的選項如下 --prefix=$HOME/usr/arm --with-headers=$HOME/usr/arm/glibc/arm-linux-glibc/include --with-libs=$HOME/usr/arm/glibc/arm-linux-glibc/lib
報錯：
configure: error: you must configure in a separate build directory
很奇怪的問題，必須配置一個構建目錄，剛開始以為是安裝目錄為創建
$mkdir /usr/local/glibc
問題仍然存在，網路之
$mkdir ../glibc-build && cd ../glibc-build
$../glibc-2.16.0/configure --prefix=/usr/local/glibc
出現新的問題：
configure: WARNING:
*** These auxiliary programs are missing or incompatible versions: msgfmt
*** some features will be disabled.
*** Check the INSTALL file for required versions.
checking LD_LIBRARY_PATH variable... contains current directory
configure: error:
*** LD_LIBRARY_PATH shouldn't contain the current directory when
*** building glibc. Please change the environment variable
*** and run configure again.
第一個警告不用管它，第二個LD_LIBRARY_PATY也會有錯？我的這個路徑用了多少天了。仔細看提示，不應包含當前路徑。打開~/.bash_profile
$cat ~/.bash_profile
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib export LD_LIBRARY_PATH
這也沒當前路徑啊。還是網路吧。
一個兄弟的解釋是這樣「LD_LIBRARY_PATH不能以終結符作為開始和最後一個字元，不能有2個終結符連在一起，我的LD_LIBRARY_PATH為 :/usr/local/firefox:/usr/local/firefox,只要在前面加上一個路徑，不讓：出現在第一個字元就可以了 」
原來如此，第一個字元不能是":"，修改~/.bash_profile
export LD_LIBRARY_PATH=/usr/local/lib export LD_LIBRARY_PATH
$../glibc-2.16.0/configure --prefix=/usr/local/glibc
ls一下，發現，當前目錄生成了Makefile等一堆東西
$make && make install
沒問題
下一步開始交叉編譯
$mkdir ../glibc-build-mips && cd ../glibc-build-mips
$ ../glibc-2.16.0/configure --prefix=/usr/local/glibc_mips CC=mipsel-linux-gcc --host=mips
出現新的問題：
configure: running configure fragment for add-on libidn
configure: running configure fragment for add-on nptl
*** The GNU C library is currently not available for this platform.
*** So far nobody cared to port it and if there is no volunteer it
*** might never happen. So, if you have interest to see glibc on
*** this platform visit
*** http://www.gnu.org/software/libc/porting.html
*** and join the group of porters
看起來像是需要path，下載glibc-ports-2.16.tar.gz，放在源碼包目錄，解壓
$ ../glibc-2.16.0/configure \
--prefix=/usr/local/glibc_mips \
CC=mipsel-linux-gcc \
CXX=mipsel-linux-g++ \
--host=mips \
--enable-add-ons=/home/hb/code/glibc/glibc-ports-2.16.0/sysdeps/mips
仍然報錯：
configure: error: fragment must set $libc_add_on_canonical
改為：
$ ../glibc-2.16.0/configure \
--prefix=/usr/local/glibc_mips \
CC=mipsel-linux-gcc \
CXX=mipsel-linux-g++ \
--host=mips \
--enable-add-ons
報錯：
configure: error: The mipsel is not supported.
這樣不行，谷歌半天，總算知道補丁怎麼用的了。把補丁目錄拷到glibc目錄下，改名為ports
$mv glibc-ports-2.16.0/ glibc-2.16.0/ports
$../glibc-2.16.0/configure \
--prefix=/usr/local/glibc_mips \
CC=mipsel-linux-gcc \
CXX=mipsel-linux-g++ \
--host=mipsel-linux \
--build=i686-pc-linux-gnu \
--enable-add-on
繼續報錯：
configure: error:
*** These critical programs are missing or too old: ld as
*** Check the INSTALL file for required versions.
這個問題可折騰死我了。弄了好半天，就是不行，最後google發現，原來是ld和as版本不對，不是太高就是太低。
configure中找到$AS --version
發現版本是這么匹配的2.1*.*
$mipsel-linux-ld
GNU ld (GNU Binutils) 2.18.50.20080908
原來是這樣，在configure版本號那一行修改，最後的括弧前面加入
|2.18.50.×
as那一行也同樣修改
然後
$make
開始編譯，看起來不錯
好半天後，編譯也報錯了
In file included from ../include/uchar.h:1,
from mbrtoc16.c:23:
../wcsmbs/uchar.h:47:5: error: #error "<uchar.h> requires ISO C11 mode"
In file included from ../include/uchar.h:1,
from mbrtoc16.c:23:
../wcsmbs/uchar.h:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char16_t'
../wcsmbs/uchar.h:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char32_t'
../wcsmbs/uchar.h:61: error: expected ')' before '*' token
../wcsmbs/uchar.h:66: error: expected declaration specifiers or '...' before 'char16_t'
../wcsmbs/uchar.h:73: error: expected ')' before '*' token
../wcsmbs/uchar.h:78: error: expected declaration specifiers or '...' before 'char32_t'
mbrtoc16.c:37: error: expected ')' before '*' token
make[2]: *** [/home/hb/code/glibc/glibc-build-mips/wcsmbs/mbrtoc16.o] 錯誤 1
make[2]:正在離開目錄 `/home/hb/code/glibc/glibc-2.16.0/wcsmbs'
make[1]: *** [wcsmbs/subdir_lib] 錯誤 2
make[1]:正在離開目錄 `/home/hb/code/glibc/glibc-2.16.0'
make: *** [all] 錯誤 2
看看這個頭文件咋回事
$ vim ../glibc-2.16.0/wcsmbs/uchar.h
#if defined __GNUC__ && !defined __USE_ISOCXX11
/* Define the 16-bit and 32-bit character types. Use the information
provided by the compiler. */
# if !defined __CHAR16_TYPE__ || !defined __CHAR32_TYPE__
# if defined __STDC_VERSION__ && __STDC_VERSION__ < 201000L
# error "<uchar.h> requires ISO C11 mode"
# else
# error "definitions of __CHAR16_TYPE__ and/or __CHAR32_TYPE__ missing"
# endif
# endif
明白了，原來是需要c11支持，mipsel-linux-gcc -v一下，我的支持c99.原來如此。暫時沒招了，我還做不到修改c11的支持，只剩兩個辦法，不用這個glibc版本或者重新編譯一個支持c11的交叉編譯器。編譯器需要做的比較多，暫時先換個低點的版本吧。
下載galibc-2.15版本
重復上面步驟，解壓tar包
解壓ports包
$mv glibc-ports-2.15 glibc-2.15/ports
$mkdir glibc-build-2.15 &&cd glibc-build-2.15
$ ../glibc-2.15/configure \
--prefix=/usr/local/glibc_mips \
CC=mipsel-linux-gcc \
--host=mipsel-linux \
--build=i686-pc-linux-gnu \
--enable-add-on=nptl \
libc_cv_forced_unwind=yes \
libc_cv_c_cleanup=yes \
libc_cv_mips_tls=yes \
libc_cv_gnu99_inline=yes
ok,沒問題
$make &&make install
庫已經編好了，但是不能直接使用，必須再用新的庫重編一遍編譯器才行。
上一篇