hisiv400+glibc-2.23编译
使用hisi编译，glibc库 笔记记录。
./configure 时不使用--with-headers 选项的处理方式，
：这时候编译glibc时默认寻找，宿主机include/ 路径及usr/asm/include/下asm等路径下头文件。
首先从gnu官网下载最新版的glibc，地址http://www.gnu.org/software/libc/
$tar xvf glibc-2.23.tar.bz
$cd glibc-2.23
$./configure --prefix=/user1/yueyc/hisi-glibc-2.23 --host=arm-linux --enable-add-on=nptl CC=arm-hisiv400-linux-gcc CXX=arm-hisiv400-linux-g++
报错：configure: error: you must configure in a separate build directory提示错误，需要在独立的build目录下，进行configure 。在一个新的路径下 从新.configure 即可
$./glibc-2.23/configure --prefix=/user1/yueyc/hisi-glibc-2.23 --host=arm-linux --enable-add-on=nptl CC=arm-hisiv400-linux-gcc CXX=arm-hisiv400-linux-g++
configure通过，make通过 ；makeinstall 通过；
./configure 时使用--with-headers 选项的处理方式，这个时候可以选择不同版本内核的头文件进行glibc的交叉编译
宿主机：cetos5.4 linux2.6.18
目标机：hisi3536 + linux3.10.y
.
制作库的文件路径架构
glibc-2.23的源码路径 ： usr/xxx/glibc2.23/build/glibc-2.23 /SourceDir
glibc-2.23的配置路径： usr/xxx/glibc2.23/ /ConfigDir
glibc-2.23的安装路径： usr/xxx/glib2.23_install/ /InstallDir
linux3.10.y源码路径： usr/xxx/kernel_3536/ /KernelDir
1.进入linux3.10.y 源码路径执行，头文件安装指令,将头文件安装到glibc的预安装目录下，等待make glibc时使用。
make ARCH=arm CROSS_COMPILE=arm-hisiv400-linux- INSTALL_HDR_PATH=/usr/xxx/glib2.23_install/ headers_install
make ARCH=arm CROSS_COMPILE=$gcc INSTALL_HDR_PATH=$InstallDir headers_install
在usr/xxx/glib2.23_install/下会生成include文件夹及下属文件。
2、进入usr/xxx/glibc2.23/路径下，进行./configure 配置
./glibc-2.23/configure --prefix=/usr/xxx/glibc2.23_install --host=arm-linux --enable-add-ons --with-headers=/usr/xxx/glibc2.23_install/include CC=arm-hisiv400-linux-gcc CXX=arm-hisiv400-linux-g++
3.configure 通过，make通过，make install 通过。
刚开始的时候把--with-headers=usr/xxx/kernel_3536/inlclude ，将头文件依赖直接指到了kernel源码的include路径上，configure通过后make时会报错：
if test -r /mnt/LFS/build/glibc-2.12.1-BUILD/csu/abi-tag.h.new; then
mv -f /mnt/LFS/build/glibc-2.12.1-BUILD/csu/abi-tag.h.new
/mnt/LFS/build/glibc-2.12.1-BUILD/csu/abi-tag.h; \
else echo >&2 'This configuration not matched in ../abi-tags'; exit 1; fi
mv -f /mnt/LFS/build/glibc-2.12.1-BUILD/csu/version-info.hT
/mnt/LFS/build/glibc-2.12.1-BUILD/csu/version-info.h
make[2]: Leaving directory `/mnt/LFS/build/glibc-2.12.1/csu'
make[1]: *** [csu/subdir_lib] Error 2
make[1]: Leaving directory `/mnt/LFS/build/glibc-2.12.1'
make: *** [all] Error 2
会有很多文件缺失的错误。被老外不少馊主意比如说cp -r arch/arm/include include之类的小坑了一下。
sysdeps/unix/sysv/linux/sys/syscall.h:25:24: fatal error:
asm/unistd.h: No such file or directory
compilation terminated.
感谢：http://hezhao2000.blog.163.com/blog/static/1224363672012101253110848/ 在路上。。。
关于：--enable-add-on=nptl 选项 说明：http://blog.csdn.net/guosha/article/details/2960186
POSIX Thread Library (NPTL)使Linux内核可以非常有效的运行使用POSIX线程标准写的程序。
这里有一个测试数据，在32位机下，NPTL成功启动100000个线程只用了2秒，而不使用NPTL将需要大约15分钟左右的时间。
历史
在内核2.6以前的调度实体都是进程，内核并没有真正支持线程。它是能过一个系统调用clone()来实现的，这个调用创建了一份调用进程的拷贝，跟fork()不同的是,这份进程拷贝完全共享了调用进程的地址空间。LinuxThread就是通过这个系统调用来提供线程在内核级的支持的(许多以前的线程实现都完全是在用户态，内核根本不知道线程的存在)。非常不幸的是，这种方法有相当多的地方没有遵循POSIX标准，特别是在信号处理，调度，进程间通信原语等方面。
很显然，为了改进LinuxThread必须得到内核的支持，并且需要重写线程库。为了实现这个需求，开始有两个相互竞争的项目：IBM启动的NGTP(Next Generation POSIX Threads)项目，以及Redhat公司的NPTL。在2003年的年中，IBM放弃了NGTP，也就是大约那时，Redhat发布了最初的NPTL。
NPTL最开始在redhat linux 9里发布，现在从RHEL3起内核2.6起都支持NPTL，并且完全成了GNU C库的一部分。
设计
NPTL使用了跟LinuxThread相同的办法，在内核里面线程仍然被当作是一个进程，并且仍然使用了clone()系统调用(在NPTL库里调用)。但是，NPTL需要内核级的特殊支持来实现，比如需要挂起然后再唤醒线程的线程同步原语futex.
NPTL也是一个1*1的线程库，就是说，当你使用pthread_create()调用创建一个线程后，在内核里就相应创建了一个调度实体，在linux里就是一个新进程，这个方法最大可能的简化了线程的实现。
除NPTL的1*1模型外还有一个m*n模型，通常这种模型的用户线程数会比内核的调度实体多。在这种实现里，线程库本身必须去处理可能存在的调度，这样在线程库内部的上下文切换通常都会相当的快，因为它避免了系统调用转到内核态。然而这种模型增加了线程实现的复杂性,并可能出现诸如优先级反转的问题，此外，用户态的调度如何跟内核态的调度进行协调也是很难让人满意。