glibc源码包

‘壹’ 在哪里可以找到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
库已经编好了，但是不能直接使用，必须再用新的库重编一遍编译器才行。

上一篇