目录
三、glibc, uClibc, Elibc的渊源/历史/区别/联系
一、为什么使用交叉编译工具链
在进行嵌入式开发时，目标平台，即嵌入式开发板，比如是最大主频200MHz的ARM的CPU，加上32M的RAM，加上1G的Nand Flash等等。在如此相对比较紧张的硬件资源的前提下，在已经运行了嵌入式Linux的前提下，是没法很方便的，直接在嵌入式Linux下，去本地编译，去在ARM的CPU下，编译出来，供ARM的CPU可以运行的程序的。
因为编译，开发，都需要相对比较多的CPU，内存，硬盘等资源，而嵌入式开发上的那点资源，只够嵌入式（Linux）系统运行的，没太多剩余的资源可供本地编译。
二、交叉编译器的命名规则
crosstool-ng中，交叉编译器的(前缀)的名字的命名规则：
arch-vendor-kernel-system
对应分别是 :
arch [-vendor] [-os] [-(gnu)eabi]
| 规则 | 描述 |
|---|---|
| arch | 体系架构, 如ARM, MIPS |
| vendor | 工具链提供商 |
| os | 目标操作系统 |
| eabi | 嵌入式应用二进制接口(Embedded Application Binary Interface) |
三、C语言的三种标准库
1.Glibc
glibc = GNU C Library
是GNU项（GNU Project）目，所实现的 C语言标准库（C standard library）。
目前，常见的桌面和服务器中的GNU/Linux类的系统中，都是用的这套C语言标准库。
其实现了常见的C库的函数，支持很多种系统平台，功能很全，但是也相对比较臃肿和庞大。
2.uClibc
一个小型的C语言标准库，主要用于嵌入式。
其最开始设计用于uClinux（注：uClinux不支持MMU），因此比较适用于微处理器中。
对应的，此处的u意思是μ，Micro，微小的意思。
uClibc的特点：
(1)uClibc比glibc要小很多。
(2)uClibc是独立的，为了应用于嵌入式系统中，完全重新实现出来的。和glibc在源码结构和二进制上，都不兼容。
3.EGLIBC
EGLIBC = Embedded GLIBC
EGLIBC是，（后来）glibc的原创作组织FSF所（新）推出的，glibc的一种变体，目的在于将glibc用于嵌入式系统。
EGLIBC的目标是：
(1)保持源码和二进制级别的兼容于Glibc
源代码架构和ABI层面兼容
如果真正实现了这个目标，那意味着，你之前用glibc编译的程序，可以直接用eglibc替换，而不需要重新编译。
这样就可以复用之前的很多的程序了。
(2)降低(内存)资源占用/消耗
(3)使更多的模块为可配置的（以实现按需裁剪不需要的模块）
(4)提高对于交叉编译(cross-compilation)和交叉测试(cross-testing)的支持
三、glibc, uClibc, Elibc的渊源/历史/区别/联系
1. 写程序，需要用到很多c语言的库函数。所有的库函数加起来，就是对应的C语言（标准）函数库。 2. 目前在普通GNU/Linux系统中所用的C语言标准库，叫做glibc。其功能很全，函数很多，但是代码太多，编译出来的函数库的大小也很大，即资源占用也很多。 3. 而嵌入式系统中，也需要C语言写代码实现特定功能，也需要用到C语言函数库，但是由于嵌入式系统中，一般资源比较有限，所以不适合直接使用（太占用资源的）gLibc。 4. 所以有人就又（没有参考glibc，而是从头开始，）重新实现了一个用于嵌入式系统中的，代码量不是很大的，资源占用相对较少的，C语言函数库，叫做uClibc。并且，uClibc不支持MMU（内存管理单元）。 5. 而后来，glibc的开发者，又推出个Embedded glibc，简称eglibc，其主要目的也是将glibc用于嵌入式领域。 相应最大的改动就在于，把更多的库函数，改为可配置的，这样，如果你的嵌入式系统中不需要某些函数，就可以裁剪掉，不把该函数编译到你的eglibc库中，使得最终生成的eglibc库的大小变小，最终符合你的嵌入式系统的要求（不能超过一定的大小），这样，就实现了，把glibc引用于嵌入式系统中的目的了。
glibc，uClibc，eglibc都是C语言函数库：
1. uClibc是嵌入式系统中用的，glibc是桌面系统用的
2. eglibc也是嵌入式系统中用的，是glibc的嵌入式版本，和glibc在源码和二进制上兼容。
Eglibc的最主要特点就是可配置，这样对于嵌入式系统中，你所不需要的模块，比如NIS，locale等，就可以裁剪掉，不把其编译到库中，使得降低生成的库的大小了。
更多特点，可以去看：Eglibc的特点
【目前了解到的海思交叉编译工具链的应用环境】
arm-hisiv100-linux为基于uclibc的工具链，arm-hisiv200-linux 为基于 glibc 的工具链；
arm-hisiv300-linux为基于uclibc的工具链，arm-hisiv400-linux 为基于 glibc 的工具链；
arm-hisiv500-linux为基于uclibc的工具链，arm-hisiv600-linux 为基于 glibc 的工具链。
（在开发的时候，你编译内核所用的交叉编译链跟用户的应用程序所用的交叉编译链一定需要相同，不然没法调用系统内核的依赖库）
其中eglibc这种很容易被人开发者忽视，从而选错了编译工具链。
uClibc和Glibc并不相同，两者有许多不同之处，有可能给你带来一些问题。
四、uclibc和glibc的差别
1. uClibc比Glibc小，虽然uClibc和Glibc在已有的接口上是兼容的，而且采用uClibc编译应用程序比采用Glibc编译应用程序要更方便，但是uClibc并没有包括Glibc中的所有接口实现，因此有些应用可能在uClibc中不能编译。
2. uClibc在可配置性上比Glibc要好。
3. uClibc并不能保证发布的库二进制兼容旧版本uClibc库。当一个新的版本uClibc库被发布，则可能需要也可能不需要重新编译应用程序。
4. 在Glibc中调用malloc(0)，将返回一个有效的指针，然而在uClibc中调用malloc(0)，则返回NULL指针。根据在SuSv3中关 于malloc(0)的行为的定义，两个库的实现都是正确的。对于调用relloc(NULL,0)，两个库的实现也不同。个人感觉Glibc的如此实现 不是特别安全。Glibc中malloc的实现可以通过MALLOC_CHECK_ 环境变量调节。这个方法主要用于malloc调试。这些扩展的malloc调试特性在uClibc中是不可用的。在Linux上有许多有些的malloc 调试功能的库(如：dmalloc,electric fence,valgrind等)比Glibc中的扩展的malloc调试功能更好用。因此uClibc中去掉这些功能特性并不会有多打损失。
5. uClibc没有提供用于数据接口的库(libdb)。
6. uClibc不支持NSS(/lib/libnss_*)，在这方面Glibc更容易支持不同方式的认证和DNS解析。uClibc仅仅支持采用flat口令文件或者shadow口令文件存储授权信息。如果需要比这些更复杂的的授权，可以编译安装pam。
7. uClibc中的libresolv库仅仅是一个桩。Glibc的libresolv库中的部分并不是全部的功能uClibc都提供，许多函数都没有实现。
8.提供网络信息服务支持(NIS)libnsl库(最初被称为黄页YP)，被SUN扩展为发明为RPC并用于网络共享Unix口令文件。个人认为NIS 是一个令人厌恶的东西并应该使用。因此，在实现相同的功能情况下采用ldap比NIS更有效。uClibc虽然提供一个桩libnsl，但并不支持 NIS。我们因此也不提供在Glibc下提供的位于/usr/include/rpcsvc里的头文件。
9. uClibc的区域支持并不是100%的完全。正在这方面努力
10.uClibc的数据功能函数库内部仅仅支持long double，设置对于long double的支持也是非常有限。与此对应的只实现了较少的数学函数。如果应用程序采用double类型，则会程序会运行得较好。
11. uClibc的libcrpt库不支持可重入crypt_r,setkey_r和encrypt_r，因为这些也不是SuSv3所规定的。
12. uClibc直接采用内核的数据类型去定义大多数透明的数据类型。
13. uClibc支持采用linux内核结构特有的结构体"struct stat"。
14. uClibc的运行时库librt当前缺少aio接口、全部的时钟接口和共享内存接口(仅仅实现定时器接口和消息队列接口)