Loading AI tools
GNU开发的C标准库 来自维基百科,自由的百科全书
GNU C库,又名glibc,是GNU计划所实现的C标准库。尽管其名字中带有“C库”,但它现在也直接支持C++(以及间接支持其他编程语言)。它是自由软件基金会(FSF)在20世纪90年代初为他们的GNU操作系统设计的。它为GNU系统,GNU/Linux系统和一些其他的类Unix系统提供了系统核心库。这些库提供了关键的API,包括ISO C11、POSIX.1-2008和BSD所规定的API和一些底层API,包括open、read、write、malloc、printf、getaddrinfo、dlopen、pthread_create、crypt、login、exit等。
glibc在GNU宽通用公共许可证下发布。[3]
glibc项目最初主要由Roland McGrath编写,他在20世纪80年代为自由软件基金会(FSF)工作。[4]
1988年,FSF称glibc已基本实现ANSI C所规定的内容[5] ;到1992年,它已经实现了ANSI C-1989和POSIX.1-1990所规定的功能,并正在进行关于实现POSIX.2的工作。[6]
1995年9月,Ulrich Drepper为glibc项目做出了他的第一个贡献,并在20世纪90年代逐渐成为glibc的核心贡献者和维护者。[7] Drepper担任维护员一职多年,直到2012年累计占项目总贡献的63%。[8]
在20世纪90年代初,Linux内核的开发团队分叉了Glibc,名为“Linux libc”并单独维护。
当FSF在1997年1月发布glibc 2.0时,由于glibc 2.0更符合POSIX标准,内核开发者停止了Linux libc的开发。[9] glibc 2.0还具有更好的国际化和翻译、IPv6功能、64位数据访问、多线程支持、未来版本的兼容性,而且代码更加可移植。[10]
最后版本的Linux libc使用的库文件名是libc.so.5
。因此,Linux上的glibc 2.x使用的库文件名称为libc.so.6
。[11] (Alpha 和 IA64 平台的glibc使用libc.so.6.1代替). 这些以.so为后缀的文件通常被缩写为libc6 (例如在Debian的软件包名中),遵循一般库的惯例。
根据Richard Stallman的说法,由于开发者们的身份模糊,FSF无法将Linux libc做出的改动合并到glibc中。GNU项目对著作权相关的要求十分严格。[12]
自2001年起,库的开发由 [13]一个监管委员会负责,[14]但保留了Drepper主要贡献者和维护者的身份。委员会的设立被Drepper公然说成是Richard Stallman的阴谋诡计,因而被公共争议所包围。[15][16][17]
glibc以前被储存在CVS仓库中,2009年被迁移到Sourceware上的Git仓库。.[18]
2012年3月,委员会投票决定解散,并撤销Drepper的职务,转而由Ryan Arnold、Maxim Kuvyrkov、Joseph Myers、Carlos O'Donell和Alexandre Oliva负责glibc的维护工作。但是,他们对于glibc没有额外的决策权。[19][20]
在委员会解散后,Debian和其他使用glibc替代品的项目又迁移回到了glibc。[21] 从2014年开始,EGLIBC不再开发,因为它“现在的目标是在glibc上直接解决问题”。[22]
2017年7月,在glibc创立30年时,Roland McGrath宣布不再直接参与项目,并宣布自己为名誉维护者。“过去这几个月,甚至过去几年,已经证明你们不再需要我了”。[4]
对于大多数系统来说,glibc的版本可以通过解析lib文件(例如,/lib/libc.so.6)获得。
版本 | 日期 | 注释 | 使用该版本的操作系统 |
---|---|---|---|
0.1 – 0.6 | 1991-10 – 1992-02 | ||
1.0 | 1992-02 | ||
1.01 – 1.09.3 | 1992-03– 1994-12 | ||
1.90 – 1.102 | 1996-05– 1997-01 | ||
2.0 | 1997-01 | ||
2.0.1 | 1997-01 | ||
2.0.2 | 1997-02 | ||
2.0.91 | 1997-12 | ||
2.0.95 | 1998-07 | ||
2.1 | 1999-02 | ||
2.1.1 | 1999-03 | ||
2.2 | 2000-11 | ||
2.2.1 | 2001-01 | ||
2.2.2 | 2001-02 | ||
2.2.3 | 2001-03 | ||
2.2.4 | 2001-07 | ||
2.3 | 2002-10 | ||
2.3.1 | 2002-10 | ||
2.3.2 | 2003-02 | Debian 3.1 (Sarge) | |
2.3.3 | 2003-12 | ||
2.3.4 | 2004-12 | 支持LSB3.0 | RHEL 4 (Update 5) |
2.3.5 | 2005-04 | SLES 9 | |
2.3.6 | 2005-11 | Debian 4.0 (Etch) | |
2.4 | 2006-03 | 支持LSB4.0,基本的 inotify 支持 | SLES 10 |
2.5 | 2006-09 | 完整的inotify支持 | RHEL 5 |
2.6 | 2007-05 | ||
2.7 | 2007-10 | Debian 5 (Lenny), Ubuntu 8.04 | |
2.8 | 2008-04 | ||
2.9 | 2008-12 | ||
2.10 | 2009-05 | ||
2.11 | 2009-10 | SLES 11, Ubuntu 10.04, eglibc used in Debian 6 (Squeeze) | |
2.12 | 2010-05 | RHEL 6 | |
2.13 | 2011-01 | eglibc 2.13 used in Debian 7 (Wheezy) | |
2.14 | 2011-06 | ||
2.15 | 2012-03 | Ubuntu 12.04 and 12.10 | |
2.16 | 2012-06 | x32 ABI支持 ,遵守 C11, SystemTap | |
2.17 | 2012-12 | 64位ARM 支持 | Ubuntu 13.04, RHEL 7 |
2.18 | 2013-08 | 加入 C++11支持。支持英特尔TSX锁精确定位。支持Xilinx MicroBlaze和IBM POWER8微架构。 | Fedora 20 |
2.19 | 2014-02 | GNU 间接函数 (IFUNC) 支持 ppc32 和 ppc64。新增功能测试宏 _DEFAULT_SOURCE,以取代 _SVID_SOURCE 和 _BSD_SOURCE。在手册中对所有功能进行了初步的安全记录。对 s390/s390x 的 ucontext 和 jmp_buf 进行了 ABI 更改。 | Ubuntu 14.04, Debian 8 (Jessie)所使用的eglibc 2.19, openSUSE 13, SLES 12 |
2.20 | 2014-09 | 支持文件描述锁 | Fedora 21 |
2.21 | 2015-02 | 新的旗语实现 | Ubuntu 15.04, Fedora 22 |
2.22 | 2015-08 | 支持启用 Google Native Client (NaCl) | Fedora 23 |
2.23 | 2016-02 | Unicode 8.0 | Fedora 24, Ubuntu 16.04 |
2.24 | 2016-08 | 删除了一些过时的功能 | Fedora 25, Ubuntu 16.10 and 17.04, Debian 9 (Stretch) |
2.25 | 2017-02 | getentropy 和 getrandom 函数, 以及 <sys/random.h> 头文件 被加入 |
Fedora 26 |
2.26 | 2017-08 | 提高性能(malloc的线程缓存),支持Unicode 10。 | Fedora 27, Ubuntu 17.10 |
2.27 | 2018-02 | 性能提升. RISC-V 支持 | Fedora 28, Ubuntu 18.04 |
2.28 | 2018-08 | statx , renameat2 , Unicode 11.0.0 |
Ubuntu 18.10,[23] RHEL 8.0.0,[24] Debian 10 (Buster),[25] Fedora 29[26][27] |
2.29 | 2019-02 |
|
Ubuntu 19.04,[29] Fedora 30[30][31] |
2.30 | 2019-02 | Unicode 12.1.0, 动态链接器接受--preload 参数来预载共享对象,Linux上增加了gettid 函数, 支持民国历, 新的日本年代被加入 ja_JP locale;总对象大小大于PTRDIFF_MAX 时内存分配函数失效; CVE-2019-7309和 CVE-2019-9169 被修复[32] |
Ubuntu 19.10,[33] Fedora 31[34] |
2.31 | 2020-02 | 加入 C2x 标准支持 | Ubuntu 20.04,[35] Fedora 32[36] |
2.32 | 2020-08 | Unicode 13.0,'access' 属性在GCC 10中提供更友好的警告,即 "帮助检测缓冲区溢出和其他越界访问"。[37] | Ubuntu 20.10, Fedora 33 |
2.33 | 2021-02 | 加入HWCAPS标志 | Ubuntu 21.04, Fedora 34 |
2.34 | 2021-08 | libpthread, libdl, libutil, libanl 被集成进libc中 | Ubuntu 21.10, RHEL 9.0.0, Fedora 35 |
2.35 | 2022-02 | Unicode 14.0, C.UTF-8 locale, restartable sequences.
移除 Intel MPX 支持 |
Ubuntu 22.04, Fedora 36 |
2.36 | 2022-08 | Ubuntu 22.10 | |
2.37 | 2023-02 |
glibc实现了单一UNIX规范、POSIX(1c、1d和1j)所要求的功能,并实现了ISO C11、ISO C99、Berkeley Unix(BSD)接口、System V接口定义(SVID)和X/Open Portability Guide(XPG)4.2所要求的部分功能,并提供了所有符合XSI(X/Open System Interface)的系统所共有的扩展以及所有X/Open UNIX扩展。
此外,glibc还提供了在开发GNU时被认为有用或必要的扩展。
glibc可以运行在许多不同的内核和不同的硬件架构上。官方支持的硬件架构[38] 包括: 32位ARM,AArch64, C-SKY, DEC Alpha, IA-64, Motorola m68k, MicroBlaze, MIPS, Nios II, PA-RISC, PowerPC, RISC-V, s390, SPARC, 和 x86 (旧版本支持 TILE)。Glibc官方支持Hurd和Linux内核。此外,还有大量打过补丁的版本可以运行在FreeBSD和NetBSD上(因此glibc也相应地支持Debian GNU/kFreeBSD和Debian GNU/NetBSD,因为这些内核与FreeBSD和NetBSD的关联很大),以及OpenSolaris的分支版本。[39] Glibc的一个修改过的版本也被用在 BeOS 和 Haiku中。[40]
Glibc在过去因过于臃肿且速度比其他C库较慢,遭到一些开发者们的批评,如Linus Torvalds[41] 和一些嵌入式开发程序员。 出于这个原因,人们创建了几个用于在嵌入式平台替代Glibc的C标准库。这些库较Glibc更小。然而,许多嵌入式开发项目仍使用Glibc,因为它更加符合标准且兼容性更好。例如Openmoko[42] 和由iPaq使用的Familiar Linux(在使用GPE显示软件时)[43]。
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.