当前位置: 首页 > 工具软件 > uClibc > 使用案例 >

uclibc和glibc的定义与区别

丌官星渊
2023-12-01

定义

Glibc

glibc = GNU C Library
是GNU项(GNU Project)目,所实现的 C语言标准库(C standard library)。
目前,常见的桌面和服务器中的GNU/Linux类的系统中,都是用的这套C语言标准库。
其实现了常见的C库的函数,支持很多种系统平台,功能很全,但是也相对比较臃肿和庞大。

uClibc

一个小型的C语言标准库,主要用于嵌入式。
其最开始设计用于uClinux(注:uClinux不支持MMU),因此比较适用于微处理器中。
对应的,此处的u意思是μ,Micro,微小的意思。

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

uClibc的特点:
(1)uClibc比glibc要小很多。
(2)uClibc是独立的,为了应用于嵌入式系统中,完全重新实现出来的。和glibc在源码结构和二进制上,都不兼容。

EGLIBC

EGLIBC = Embedded GLIBC
EGLIBC是,(后来)glibc的原创作组织FSF所(新)推出的,glibc的一种变体,目的在于将glibc用于嵌入式系统。
EGLIBC的目标是:
(1)保持源码和二进制级别的兼容于Glibc
源代码架构和ABI层面兼容
如果真正实现了这个目标,那意味着,你之前用glibc编译的程序,可以直接用eglibc替换,而不需要重新编译。
这样就可以复用之前的很多的程序了。
(2)降低(内存)资源占用/消耗
(3)使更多的模块为可配置的(以实现按需裁剪不需要的模块)
(4)提高对于交叉编译(cross-compilation)和交叉测试(cross-testing)的支持

Eglibc的最主要特点就是可配置,这样对于嵌入式系统中,你所不需要的模块,比如NIS,locale等,就可以裁剪掉,不把其编译到库中,使得降低生成的库的大小了。
更多特点,可以去看: Eglibc的特点

联系与区别

【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在源码和二进制上兼容。

以上是粗略介绍区别,以下内容当出现问题时进行查阅

细节区别

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

 类似资料: