uclibc、glibc和uc-libc之间的区别与关系

uClinux的通用c库:uC-libc和uClibc的区别概述uClinux通常使用两种c库:uC-libc和uClibc.尽管它们名字近似,但有很大区别.本文是对它们不同点的快速浏览.
uC-libc是uClinux的原始c 库,它基于Linux-8086 c库,该c 库是ELKs 工程的一部分,支持m68000结构.uC-libc是一个相当全面的c 库,但它的一些API是非标准的,一些通用库例程现在已不再使用.目前它能稳定地支持m68000,ColdFire和ARM(不带MMU)结构 .其主要设计目标是小型化和轻量级.它力图符合通用标准,它的API也与绝大多数的c 库兼容,但与标准难免有出入.
uClibc是uC-libc的派生体,用来解决uC-libc存在的问题.它让所有的API都标准化(正确的类型,参数等),补充了许多缺失的例程,并且已经移植到许多结构中.大体上讲,它通过提供glibc兼容使得应用程序移植到较小的c 库时相当得容易. 它能够应用到带虚拟存储的Linux和uClinux上.在大多数带MMU部件的平台上为使它更加紧凑,它也能够编译成共享库.uClibc支持许多处理器:m68000,ColdFire,ARM,MIPS,v850,x86,i960,Sparc,SuperH,Alpha,PowerPC和 Hitachi 8.uClibc能更加容易地适应新的体系结构,它所支持的平台数目至今仍在增长证实了这一点.
可以根据你的需要来选择uClinux使用uC-libc或者uClibc编译环境.对m68000和ColdFire平台通常选择uC-libc, 因为它支持共享库,是这些处理器上使用最广泛的c 库.uClibc also works quite well with almost all platforms supported by the distribution.你的需要将最终决定到底选择哪一种c库.

GCC的标准库，就是glibc这个库，里面有GCC各种标准函数的实现，还有各种unix系的函数在里面。
当初创建uclinux的时候，需要一个能编译比较小体积的目标文件的便宜器，这个时候就有人写了一个
uc-libc库，这个库可以说是uclinux上的一个glibc移植，但是还是有很多函数没有实现，所以人们只能
勉强用它来在uclinux上写程序。后来，有牛人又写了uclibc,这个是真正意义上的瘦身过后的glibc,完成
了很多以前uc-libc不支持的函数。本人觉得最有价值的就是uclibc实现了pthread系列函数，以前用
uc-libc只能用fork+exec来完成的多线程功能。uclibc现在也不只是用在嵌入式系统上面，一些人 也喜欢在标准平台使用它来编译一些程序。

只是抛砖来引玉，希望大家把自己所知道的有关嵌入式uclinux编译库的东西都说说吧

uC-libc是早期版本，不要考虑了，除非你想考古。
uClibc支持动态连接，但我认为目前uClibc的优势还是在静态连接上。比glibc自然小很多，是否选择uClibc因素很多，比如看你的文件系统大小，如果超过20M，用glibc更简单，glibc已经久经考验了；如果小于4M，可以考虑用uClibc，体积小是很大的优势。

 

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接口、全部的时钟接口和共享内存接口(仅仅实现定时器接口和消息队列接口)

参考：http://hi.baidu.com/liaolihome/blog/item/88eefb73dddc9d1a8701b077.html     uClibc和Glibc的区别

http://hi.baidu.com/linuxlightus/blog/item/ec72c7303539e7b9d1a2d360.html               uclibc、glibc和uc-libc之间的区别与关系