GNU C函式庫

  「glibc」重定向至此，您可能想尋找頁面GLib或Gnulib。
GNU C库
原作者Roland McGrath
開發者GNU计划
首次发布1987年，​37年前​（1987）[1]
当前版本
  • 2.40（2024年7月22日；穩定版本）[2]
編輯維基數據鏈接
源代码库
編輯維基數據鏈接
编程语言C语言
操作系统类UNIX系统
类型库
许可协议LGPLv2.1[3]
网站www.gnu.org/software/libc/
Linux API由Linux内核的系统调用接口、GNU C库（GNU）、libdrm、libalsa和libevdev组成。
Glibc是Linux内核系统调用的封装器。
Linux内核和GNU C库共同构成了Linux API。编译后，二进制文件提供ABI。

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]

Linux libc

[编辑]

在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]

迁移到git

[编辑]

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）获得。

功能

[编辑]

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]。

相關條目

[编辑]

参考资料

[编辑]
  1. ^ Corbet, Jonathan. A turning point for GNU libc. LWN.net. 2012-03-28 [2013-02-05]. （原始内容存档于2016-04-23）. 
  2. ^ The GNU C Library version 2.40 is now available. 2024年7月22日 [2024年7月23日]. 
  3. ^ 3.0 3.1 sourceware.org Git - glibc.git/blob - COPYING.LIB. sourceware.org. [2017-09-23]. 
  4. ^ 4.0 4.1 Roland McGrath bows out as glibc maintainer [LWN.net]. lwn.net. 2017-07-07 [2017-07-08]. （原始内容存档于2020-08-01）. 
  5. ^ GNU's Bulletin， vol. 1 no. 4， February， 1988. [2020-10-24]. （原始内容存档于2016-04-16）. Most libraries are done. Roland McGrath […] has a nearly complete set of ANSI C library functions. We hope they will be ready some time this spring. 
  6. ^ GNU's Bulletin， vol. 1 no. 12. [2020-10-24]. （原始内容存档于2016-03-11）. It now contains all of the ANSI C-1989 and POSIX.1-1990 functions， and work is in progress on POSIX.2 and Unix functions (BSD and System V) 
  7. ^ glibc changelog on GitHub.
  8. ^ Corbet, Jonathan. A turning point for GNU libc. LWN.net. 2012-03-28 [2013-02-05]. （原始内容存档于2016-04-23）. Of the nearly 19，000 commits found in the project's git repository (which contains changes back to 1995)， over 12，000 were made by Ulrich. 
  9. ^ Forking: it could even happen to you. 2008-09-12 [2020-10-24]. （原始内容存档于2009-09-15）. the split between GNU LIBC and the Linux LIBC -- it went on for years while Linux stabilized， and then the forks re-merged into one project 
  10. ^ Lee, Elliot. A Technical Comparison of glibc 2.x With Legacy System Libraries. 2001 [2020-10-24]. （原始内容存档于2004-04-11）. 
  11. ^ Fear of Forking essay， see "6. glibc --> Linux libc --> glibc". [2020-10-24]. （原始内容存档于2014-07-18）. 
  12. ^ Fear of Forking， footnote on Stallman's merge comments. [2020-10-24]. （原始内容存档于2014-07-18）. 
  13. ^ Ulrich Drepper. LinkedIn. [2012-06-13]. （原始内容存档于2014-09-10）. 
  14. ^ glibc homepage. [2020-10-24]. （原始内容存档于2016-04-22）. In 2001 The GNU C Library Steering Committee …， was formed and currently consists of Mark Brown， Paul Eggert， Andreas Jaeger， Jakub Jelinek， Roland McGrath and Andreas Schwab. 
  15. ^ Drepper, Ulrich. RMS is at it again. sourceware.org. 2000-06-26 [2015-11-20]. （原始内容存档于2012-12-28）. A few weeks ago RMS started the next attack on me (a single mail， followed by indirect tries to take influence， followed by another mail today). The essence is that he complains I am not following "GNU policies" and therefore have to be replaced by a steering committee of which I could be a part. Some of you (namely Roland and Andreas S.) probably know about this since he proposed both as other members of the committee. In addition there was Mark Brown listed (I know somebody of this name at IBM who would also fit in this group but I'm not sure whether it is really him.) Anyhow， I completely reject this. It is not helping at all， the opposite is true. First， I am not aware of any essential policies I'm violating. The only ones are that I'm not following orders from RMS which clearly have political intends (which is of course a sacrilege) and possibly that I do not care about Winblowz (if the latter counts at all). None of this will change in any way. 
  16. ^ Drepper, Ulrich. glibc 2.2.4. sourceware.com. 2001-08-15 [2015-11-29]. （原始内容存档于2016-04-09）. And now for some not so nice things. Stallman recently tried what I would call a hostile takeover of the glibc development. He tried to conspire behind my back and persuade the other main developers to take control so that in the end he is in control and can dictate whatever pleases him. This attempt failed but he kept on pressuring people everywhere and it got really ugly. In the end I agreed to the creation of a so-called "steering committee" (SC). 
  17. ^ rms-accused-of-attempting-glibc-hostile-takeover （页面存档备份，存于互联网档案馆） on slashdot.com on August 19， 2001
  18. ^ glibc repo （页面存档备份，存于互联网档案馆） on Sourceware.com
  19. ^ McGrath, Roland. glibc steering committee dissolving. Sourceware.org. 2012-03-26 [2012-06-13]. （原始内容存档于2019-09-26）. 
  20. ^ Myers, Joseph S. GNU C Library development and maintainers. Sourceware.org. 2012-03-26 [2012-06-13]. （原始内容存档于2019-09-26）. 
  21. ^ Debian is switching (back) to GLIBC. Aurélien. 2014-06-19 [2014-06-19]. （原始内容存档于2020-11-12）. 
  22. ^ Debian package changelog. [2020-10-24]. （原始内容存档于2014-12-27）. 
  23. ^ CosmicCuttlefish/ReleaseNotes - Ubuntu Wiki. wiki.ubuntu.com. [2020-10-24]. （原始内容存档于2020-12-25）. 
  24. ^ Chapter 5. RHEL 8.0.0 release Red Hat Enterprise Linux 8. Red Hat Customer Portal. [2020-10-24]. （原始内容存档于2020-11-25）. 
  25. ^ Chapter 2. What's new in Debian 10. www.debian.org. [2020-10-24]. （原始内容存档于2020-11-12）. 
  26. ^ Changes/GLIBC228. [2020-10-24]. （原始内容存档于2020-10-01）. 
  27. ^ Red Hat Bugzilla – Bug 1598403. [2020-10-24]. （原始内容存档于2020-08-01）. 
  28. ^ sourceware.org Git - glibc.git/blob - NEWS. [2020-10-24]. （原始内容存档于2022-03-21）. 
  29. ^ DiscoDingo/ReleaseNotes - Ubuntu Wiki. wiki.ubuntu.com. [2020-10-24]. （原始内容存档于2021-01-29）. 
  30. ^ Changes/GLIBC229. [2020-10-24]. （原始内容存档于2020-10-29）. 
  31. ^ Red Hat Bugzilla – Bug 1653403. [2020-10-24]. （原始内容存档于2020-08-15）. 
  32. ^ sourceware.org Git - glibc.git/blob - NEWS. [2020-10-24]. （原始内容存档于2019-09-26）. 
  33. ^ EoanErmine/ReleaseNotes - Ubuntu Wiki. wiki.ubuntu.com. [2020-10-24]. （原始内容存档于2020-11-12）. 
  34. ^ Changes/GLIBC230 - Fedora Project Wiki. fedoraproject.org. [2020-10-24]. （原始内容存档于2020-09-19）. 
  35. ^ Focal (20.04) : glibc package : Ubuntu. Launchpad. 
  36. ^ Changes/GLIBC231 - Fedora Project Wiki. fedoraproject.org. [2020-10-24]. （原始内容存档于2020-06-18）. 
  37. ^ The GNU C Library version 2.32 is now available. sourceware.org. [2020-08-13]. （原始内容存档于2020-09-28）. 
  38. ^ The GNU C Library machine maintainers.. [2020-10-24]. （原始内容存档于2016-04-18）. 
  39. ^ Bartley, David; Spang, Michael. GNU/kOpenSolaris (GNU libc/base + OpenSolaris kernel). [2008-12-16]. （原始内容存档于2019-11-06）. 
  40. ^ Haiku Source. [2020-10-24]. （原始内容存档于2016-05-01）. libroot.so is not part of GNU project and is included in Haiku source code. 
  41. ^ Torvalds, Linus. Posting to the glibc mailing list. 9 January 2002 [2020-10-24]. （原始内容存档于2015-10-12）. 
  42. ^ OpenMoko components. [2020-10-24]. （原始内容存档于2016-04-22）. We will use glibc (not uClibC) … The alternatives may save more space and be more optimized， but are more likely to give us integration headaches 
  43. ^ Re: [Familiar] Which glibc for Familiar 0.8.4  ?. [2020-10-24]. （原始内容存档于2022-03-12）. Question: which version of the GLIBC was used to build the Familiar 0.8.4 ? Answer: 2.3.3 

外部链接

[编辑]
维基共享资源上的相关多媒体资源：GNU C函式庫
检索自“https://zh.wikipedia.org/w/index.php?title=GNU_C函式庫&oldid=84395452”