GNU C Library

GNU C Library (gọi tắt là glibc) là thư viện C chuẩn đuợc viết bởi Dự án GNU. Dự án đuợc bắt đầu vào đầu những năm 1980 bởi Quỹ Phần mềm Tự do (FSF) cho hệ điều hành GNU của họ, và vẫn đuợc tiếp tục phát triển cho tới ngày nay.

GNU C Library

Tác giả gốc	Roland McGrath
Nhà phát triển	GNU Project
Phát hành lần đầu	1987; 38 năm trước (1987)[1]
Kho mã nguồn	sourceware.org/git/glibc.git
Viết bằng	C
Hệ điều hành	Unix-like
Thể loại	Runtime library
Giấy phép	LGPLv2.1[2]
Website	www.gnu.org/software/libc/

Linux API được cấu thành từ System Call Interface của nhân Linux, GNU C Library (của GNU), libdrm, libalsa và libevdev (củafreedesktop.org).

GNU C Library là một trình bao bọc xung quanh các lời gọi hệ thống của nhân Linux kernel.

Nhân Linux và glibc cùng nhau tạo thành API Linux. Sau khi biên dịch, các mã nhị phân cung cấp một ABI.

Glibc là phần mềm tự do nguồn mở, được phát hành với Giấy phép Công cộng Hạn chế GNU. Dự án cung cấp các thư viện cốt lõi cho các hệ thống GNU và GNU/Linux, cũng như nhiều hệ thống khác sử dụng nhân Linux. Các thư viện này cung cấp các API quan trọng bao gồm bao gồm các chức năng ISO C11, POSIX.1-2008, BSD dành riêng cho hệ điều hành và nhiều hơn nữa. Các API này bao gồm các chức năng cơ bản như open, read, write, malloc, printf, getaddrinfo, dlopen, pthread_create, crypt, login, exit...

Lịch sử

Glibc ban đầu được viết chủ yếu bởi Roland McGrath, người đã làm việc cho Free Software Foundation (FSF) trong những năm 1980 khi ông còn thiếu niên.^[3]

Tháng 2 năm 1988, FSF cho biết các chức năng của ANSI C gần như đã được triển khai hoàn toàn^[4]. Đến năm 1992, các chức năng của ANSI C-1989 và POSIX.1-1990 đã được triển khai và việc hỗ trợ POSIX.2 đang được tiến hành.^[5]

Tháng 9 năm 1995, Ulrich Drepper đã có đóng góp đầu tiên của mình cho dự án, và trong những năm sau đó của thập niên 1990, ông đã dần trở thành người đóng góp và duy trì chính của glibc. Drepper giữ vai trò duy trì dự án trong nhiều năm và cho đến năm 2012, ông là người thực hiện 63% số lượt đóng góp cho dự án.^[6]

Chuyển sang Git, một phân phối VCS

Trong khi trước đó lưu trữ qua CVS, từ 2009 glibc đã chuyển sang lưu trữ qua Git (một hệ thống kiểm soát phiên bản phân tán) trên Sourceware

Các phiên bản khác

Đầu những năm 1990, các nhà phát triển nhân Linux đã phân nhánh glibc. Nhánh của họ, "Linux libc", đã được duy trì riêng biệt. Tuy nhiên, do sự khác biệt về giấy phép, các thay đổi được thực hiện với Linux libc đã không thể được đưa vào glibc.

Khi FSF phát hành glibc 2.0 vào tháng 1 năm 1997, các nhà phát triển nhân Linux đã ngừng phát triển Linux libc do sự tương thích tốt hơn của glibc 2.0 với chuẩn POSIX.^[7] Ngoài ra glibc 2.0 cũng có khả năng quốc tế hóa và biên dịch tốt hơn, IPv6, truy cập dữ liệu 64-bit, tiện ích cho các ứng dụng đa luồng, khả năng tương thích với các phiên bản trong tương lai và bộ mã có khả năng cơ động cao hơn.^[8]

Phiên bản Linux libc được sử dụng cuối cùng đã sử dụng tên (soname) libc.so.5. Từ đây, glibc 2.x trên Linux sử dụng tên libc.so.6^[9] (kiến trúc Alpha và IA64 dùng libc.so.6.1 thay thế). Tên file *.so thường được viết tắt là libc6 (ví dụ trong tên gói trong Debian) theo như quy tắc thông thường cho các thư viện.

Theo Richard Stallman, FSF không thể đưa những thay đổi trong Linux libc trở lại glibc do sự bất cập trong quyền tác giả. Dự án GNU khá nghiêm ngặt về bản quyền và tác quyền.^[10]

Năm 2009, sau nhiều tranh cãi về quá trình phát triển glibc, như Debian cùng với một số dự án phụ thuộc đã chuyển sang sử dụng Eglibc, một bản của glibc được hỗ trợ bởi một côngxoocxiom gồm Freescale, MIPS, MontaVista và Wind River, có sự hỗ trợ hệ thống nhúng cũng như hỗ trợ thêm một số kiến trúc phần mềm, cùng với nhiều sự cải tiến khác. Sau đó, mã từ Eglibc đã được đưa trở lại glibc phiên bản 2.20. Năm 2014, eglibc dừng hoạt động, Debian sử dụng trở lại glibc.

Thành lập ủy ban giám sát

Bắt đầu từ năm 2001, một ủy ban đã được thành lập để giám sát việc phát triển glibc,^[11] với Ulrich Drepper^[12] giữ vai trò là người đóng góp và duy trì chính. Việc thành lập ban chỉ đạo tạo ra một cuộc tranh cãi công khai, được Ulrich Drepper miêu tả như là một việc tranh quyền tiếp quản thất bại mang tính thù địch của Richard Stallman.^[13][14]

Tháng 3 năm 2012, ủy ban này đã loại Drepper ra khỏi vai trò phát triển cũng như tự giải tán, với mong muốn về một quá trình phát triển được quản lý trực tiếp bởi cộng đồng. Ryan Arnold, Maxim Kuvyrkov, Joseph Myers, Carlos O'Donell và Alexandre Oliva chịu trách nhiệm cho việc quản lý và duy trì của GNU, tuy nhiên họ không có quyền quyết định thêm.

Lịch sử phiên bản

Trong phần lớn trường hợp, phiên bản glibc có thể được xem bằng cách thực thi tệp thư viện (ví dụ, /lib/libc.so.6).

Phiên bản	Ngày	Ghi chú	Tiếp nhận
0.1 – 0.6	October 1991 – February 1992
1.0	February 1992
1.01 – 1.09.3	March 1992 – December 1994
1.90 – 1.102	May 1996 – January 1997
2.0	January 1997
2.0.1	January 1997
2.0.2	February 1997
2.0.91	December 1997
2.0.95	July 1998
2.1	February 1999
2.1.1	March 1999
2.2	November 2000
2.2.1	January 2001
2.2.2	February 2001
2.2.3	March 2001
2.2.4	July 2001
2.3	October 2002
2.3.1	October 2002
2.3.2	February 2003		Debian 3.1 (Sarge)
2.3.3	December 2003
2.3.4	December 2004	Standard for Linux Standard Base (LSB) 3.0	RHEL 4 (Update 5)
2.3.5	April 2005		SLES 9
2.3.6	November 2005		Debian 4.0 (Etch)
2.4	March 2006	Standard for LSB 4.0, initial inotify support	SLES 10
2.5	September 2006	Full inotify support	RHEL 5
2.6	May 2007
2.7	October 2007		Debian 5 (Lenny), Ubuntu 8.04
2.8	April 2008
2.9	November 2008
2.10	May 2009
2.11	October 2009		SLES 11, Ubuntu 10.04, eglibc used in Debian 6 (Squeeze)
2.12	May 2010		RHEL 6
2.13	January 2011		eglibc 2.13 used in Debian 7 (Wheezy)
2.14	June 2011
2.15	March 2012		Ubuntu 12.04 and 12.10
2.16	June 2012	x32 ABI support, ISO C11 compliance, SystemTap
2.17	December 2012	64-bit ARM support	Ubuntu 13.04, RHEL 7
2.18	August 2013	Improved C++11 support. Support for Intel TSX lock elision. Support for the Xilinx MicroBlaze and IBM POWER8 microarchitectures.	Fedora 20
2.19	February 2014	SystemTap probes for malloc. GNU Indirect Function (IFUNC) support for ppc32 and ppc64. New feature test macro _DEFAULT_SOURCE to replace _SVID_SOURCE and _BSD_SOURCE. Preliminary safety documentation for all functions in the manual. ABI change in ucontext and jmp_buf for s390/s390x.	Ubuntu 14.04, eglibc 2.19 used in Debian 8 (Jessie), openSUSE 13, SLES 12
2.20	September 2014	Support for file description locks	Fedora 21
2.21	February 2015	New semaphore implementation	Ubuntu 15.04, Fedora 22
2.22	August 2015	Support to enable Google Native Client (NaCl), that originally ran on x86, running on ARMv7-A, Unicode 7.0	Fedora 23
2.23	February 2016	Unicode 8.0	Fedora 24, Ubuntu 16.04
2.24	August 2016	Some deprecated features have been removed	Fedora 25, Ubuntu 16.10 and 17.04, Debian 9 (Stretch)
2.25	February 2017	The getentropy and getrandom functions, and the <sys/random.h> header file have been added.	Fedora 26
2.26	August 2017	Improved performance (per-thread cache for malloc), Unicode 10 support	Fedora 27, Ubuntu 17.10
2.27	February 2018	Performance optimizations. RISC-V support.	Fedora 28, Ubuntu 18.04
2.28	August 2018	statx, renameat2, Unicode 11.0.0	Ubuntu 18.10,[15] RHEL 8.0.0,[16] Debian 10 (Buster),[17] Fedora 29[18][19]
2.29	February 2019	getcpu wrapper build and install all locales as directories with files optimized trigonomical functions Transactional Lock Elision for powercp64le ABI posix_spawn_file_actions_addchdir_np and posix_spawn_file_actions_addfchdir_np popen and system do not run atfork handlers anymore support for the C-SKY ABIV2 running on Linux strftime's default formatting of a locale's alternative year; the '_' and '-' flags can now be applied to its "%EY"[20]	Ubuntu 19.04,[21] Fedora 30[22][23]
2.30	August 2019	Unicode 12.1.0, the dynamic linker accepts the --preload argument to preload shared objects, the gettid function has been added on Linux, Minguo (Republic of China) calendar support, new Japanese era added to ja_JP locale, memory allocation functions fail with total object size larger than PTRDIFF_MAX; CVE- fixed[24]	Ubuntu 19.10,[25] Fedora 31[26]
2.31	February 2020	Initial C2x standard support	Ubuntu 20.04,[27] Fedora 32[28]
2.32	August 2020	Unicode 13.0, 'access' attribute for better warnings in GCC 10, i.e. to "help detect buffer overflows and other out-of-bounds accesses"[29]

Chức năng

glibc cung cấp chức năng được yêu cầu bởi các tiêu chuẩn Single UNIX Specification, POSIX (1c, 1d, và 1j) và một số chức năng của ISO C11, ISO C99, Berkeley Unix (BSD), System V Interface Definition (SVID) và X/Open Portability Guide (XPG), Issue 4.2, với tất cả các phần mở rộng chung cho các hệ thống tuân thủ XSI (X/Open System Interface) cùng với tất cả các phần mở rộng X/Open UNIX.

Ngoài ra, glibc còn cung cấp các tính năng mở rộng cần thiết hay hữu ích cho các phần mềm GNU cũng như các phần mềm khác.

Phần cứng và nhân được hỗ trợ

glibc được sử dụng trên nhiều kiến trúc phần cứng và hạt nhân khác nhau. Nó được sử dụng phổ biến nhất trên các hệ thống sử dụng hạt nhân Linux trên phần cứng x86, tuy nhiên, các phần cứng được hỗ trợ chính thức^[30] bao gồm: ARM 32-bit và 64-bit (AArch64), C-SKY, DEC Alpha, IA-64, Motorola m68k, MicroBlaze, MIPS, Nios II, PA-RISC, PowerPC, RISC-V, s390, SPARC, và x86 (câc bản cũ hỗ trợ TILE). Nó chính thức hỗ trợ hạt nhân Hurd và Linux. Ngoài ra, còn có các phiên bản được chỉnh sửa để chạy trên nhân của FreeBSD và NetBSD (nhờ đó mà các dự án như Debian GNU/kFreeBSD ra đời), cũng như nhánh phát triển của OpenSolaris.^[31] Nó cũng được sử dụng (ở dạng đã chỉnh sửa), mang tên libroot.so trên BeOS và Haiku.^[32]

Sử dụng glibc trên các thiết bị cỡ nhỏ

glibc đã bị chỉ trích vì sự "cồng kềnh" của nó, điển hình là từ Linus Torvalds^[33] và các nhà phát triển embedded Linux. Vì lý do này, một số dự án cung cấp các thư viện chuẩn C thay thế gọn nhẹ hơn đã xuất hiện, điển hình là uclibc hay musl. Mặc dù vậy, nhiều dự án vẫn sử dụng glibc vì tính hoàn thiện cũng như sự hỗ trợ các tiêu chuẩn kỹ thuật của nó. Các ví dụ bao gồm Openmoko^[34] và Familiar Linux cho các thiết bị cầm tay iPaq (khi sử dụng phần mềm hiển thị GPE).^[35]

Lớp tương thích

Có các lớp tương thích ("shims") cho phép chương trình được viết cho các hệ sinh thái khác chạy trên chạy trên các hệ thống cung cấp giao diện glibc. Chúng bao gồm libhybris, một lớp tương thích cho Bionic của Android, và Wine, có thể được coi là lớp tương thích từ Windows API đến glibc và các API gốc khác có sẵn trên các hệ thống tương tự Unix.

Xem thêm

• Gnulib
• Linux kernel API