GNU C函式庫
原作者 | Roland McGrath |
---|---|
開發者 | GNU計劃 |
首次發佈 | 1987年[1] |
目前版本 |
|
原始碼庫 | |
程式語言 | C語言 |
作業系統 | 類UNIX系統 |
類型 | 庫 |
許可協定 | LGPLv2.1[3] |
網站 | www |
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)獲得。
版本 | 日期 | 註釋 | 使用該版本的作業系統 |
---|---|---|---|
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]。
相關條目
參考資料
- ^ Corbet, Jonathan. A turning point for GNU libc. LWN.net. 2012-03-28 [2013-02-05]. (原始內容存檔於2016-04-23).
- ^ The GNU C Library version 2.40 is now available. 2024年7月22日 [2024年7月23日].
- ^ 3.0 3.1 sourceware.org Git - glibc.git/blob - COPYING.LIB. sourceware.org. [2017-09-23].
- ^ 4.0 4.1 Roland McGrath bows out as glibc maintainer [LWN.net]. lwn.net. 2017-07-07 [2017-07-08]. (原始內容存檔於2020-08-01).
- ^ 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.
- ^ 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)
- ^ glibc changelog on GitHub.
- ^ 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.
- ^ 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
- ^ Lee, Elliot. A Technical Comparison of glibc 2.x With Legacy System Libraries. 2001 [2020-10-24]. (原始內容存檔於2004-04-11).
- ^ Fear of Forking essay, see "6. glibc --> Linux libc --> glibc". [2020-10-24]. (原始內容存檔於2014-07-18).
- ^ Fear of Forking, footnote on Stallman's merge comments. [2020-10-24]. (原始內容存檔於2014-07-18).
- ^ Ulrich Drepper. LinkedIn. [2012-06-13]. (原始內容存檔於2014-09-10).
- ^ 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.
- ^ 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.
- ^ 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).
- ^ rms-accused-of-attempting-glibc-hostile-takeover (頁面存檔備份,存於互聯網檔案館) on slashdot.com on August 19, 2001
- ^ glibc repo (頁面存檔備份,存於互聯網檔案館) on Sourceware.com
- ^ McGrath, Roland. glibc steering committee dissolving. Sourceware.org. 2012-03-26 [2012-06-13]. (原始內容存檔於2019-09-26).
- ^ Myers, Joseph S. GNU C Library development and maintainers. Sourceware.org. 2012-03-26 [2012-06-13]. (原始內容存檔於2019-09-26).
- ^ Debian is switching (back) to GLIBC. Aurélien. 2014-06-19 [2014-06-19]. (原始內容存檔於2020-11-12).
- ^ Debian package changelog. [2020-10-24]. (原始內容存檔於2014-12-27).
- ^ CosmicCuttlefish/ReleaseNotes - Ubuntu Wiki. wiki.ubuntu.com. [2020-10-24]. (原始內容存檔於2020-12-25).
- ^ Chapter 5. RHEL 8.0.0 release Red Hat Enterprise Linux 8. Red Hat Customer Portal. [2020-10-24]. (原始內容存檔於2020-11-25).
- ^ Chapter 2. What's new in Debian 10. www.debian.org. [2020-10-24]. (原始內容存檔於2020-11-12).
- ^ Changes/GLIBC228. [2020-10-24]. (原始內容存檔於2020-10-01).
- ^ Red Hat Bugzilla – Bug 1598403. [2020-10-24]. (原始內容存檔於2020-08-01).
- ^ sourceware.org Git - glibc.git/blob - NEWS. [2020-10-24]. (原始內容存檔於2022-03-21).
- ^ DiscoDingo/ReleaseNotes - Ubuntu Wiki. wiki.ubuntu.com. [2020-10-24]. (原始內容存檔於2021-01-29).
- ^ Changes/GLIBC229. [2020-10-24]. (原始內容存檔於2020-10-29).
- ^ Red Hat Bugzilla – Bug 1653403. [2020-10-24]. (原始內容存檔於2020-08-15).
- ^ sourceware.org Git - glibc.git/blob - NEWS. [2020-10-24]. (原始內容存檔於2019-09-26).
- ^ EoanErmine/ReleaseNotes - Ubuntu Wiki. wiki.ubuntu.com. [2020-10-24]. (原始內容存檔於2020-11-12).
- ^ Changes/GLIBC230 - Fedora Project Wiki. fedoraproject.org. [2020-10-24]. (原始內容存檔於2020-09-19).
- ^ Focal (20.04) : glibc package : Ubuntu. Launchpad.
- ^ Changes/GLIBC231 - Fedora Project Wiki. fedoraproject.org. [2020-10-24]. (原始內容存檔於2020-06-18).
- ^ The GNU C Library version 2.32 is now available. sourceware.org. [2020-08-13]. (原始內容存檔於2020-09-28).
- ^ The GNU C Library machine maintainers.. [2020-10-24]. (原始內容存檔於2016-04-18).
- ^ Bartley, David; Spang, Michael. GNU/kOpenSolaris (GNU libc/base + OpenSolaris kernel). [2008-12-16]. (原始內容存檔於2019-11-06).
- ^ Haiku Source. [2020-10-24]. (原始內容存檔於2016-05-01).
libroot.so is not part of GNU project and is included in Haiku source code.
- ^ Torvalds, Linus. Posting to the glibc mailing list. 9 January 2002 [2020-10-24]. (原始內容存檔於2015-10-12).
- ^ 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
- ^ 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