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. 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... 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. 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. Đế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. 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. 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 Đầ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. 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. 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 (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. 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. 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, với Ulrich Drepper 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. 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. 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). 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. 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 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. Nó cũng được sử dụng (ở dạng đã chỉnh sửa), mang tên libroot.so trên BeOS và Haiku. glibc đã bị chỉ trích vì sự "cồng kềnh" của nó, điển hình là từ Linus Torvalds 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 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). 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. Gnulib Linux kernel API ^ Corbet, Jonathan (ngày 28 tháng 3 năm 2012). “A turning point for GNU libc”. LWN.net. ^ “sourceware.org Git - glibc.git/blob - COPYING.LIB”. sourceware.org. Truy cập ngày 13 tháng 9 năm 2017. ^ “Roland McGrath bows out as glibc maintainer [LWN.net]”. lwn.net. 7 tháng 7 năm 2017. Truy cập ngày 8 tháng 7 năm 2017. ^ “GNU's Bulletin, vol. 1 no. 4, February, 1988”. 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”. 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) ^ Corbet, Jonathan (ngày 28 tháng 3 năm 2012). “A turning point for GNU libc”. LWN.net. 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”. ngày 12 tháng 9 năm 2008. 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 (2001). “A Technical Comparison of glibc 2.x With Legacy System Libraries”. Bản gốc lưu trữ ngày 11 tháng 4 năm 2004. ^ “Fear of Forking essay, see "6. glibc --> Linux libc --> glibc"”. ^ “Fear of Forking, footnote on Stallman's merge comments”. ^ “glibc homepage”. 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. ^ “Ulrich Drepper”. LinkedIn. Truy cập ngày 13 tháng 6 năm 2012. ^ Drepper, Ulrich (26 tháng 6 năm 2000). “RMS is at it again”. sourceware.org. Truy cập ngày 20 tháng 11 năm 2015. 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 (15 tháng 8 năm 2001). “glibc 2.2.4”. sourceware.com. Truy cập ngày 29 tháng 11 năm 2015. 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). ^ “CosmicCuttlefish/ReleaseNotes - Ubuntu Wiki”. ^ “Chapter 5. RHEL 8.0.0 release Red Hat Enterprise Linux 8”. ^ “Chapter 2. What's new in Debian 10”. ^ “Changes/GLIBC228”. ^ “Red Hat Bugzilla – Bug 1598403”. ^ “sourceware.org Git - glibc.git/blob - NEWS”. ^ “DiscoDingo/ReleaseNotes - Ubuntu Wiki”. ^ “Changes/GLIBC229”. ^ “Red Hat Bugzilla – Bug 1653403”. ^ “sourceware.org Git - glibc.git/blob - NEWS”. ^ “EoanErmine/ReleaseNotes - Ubuntu Wiki”. ^ “Changes/GLIBC230”. ^ “Focal (20.04): glibc package: Ubuntu”. ^ “Changes/GLIBC231”. ^ “The GNU C Library version 2.32 is now available”. sourceware.org. Truy cập ngày 13 tháng 8 năm 2020. ^ “The GNU C Library machine maintainers”. ^ Bartley, David; Spang, Michael. “GNU/kOpenSolaris (GNU libc/base + OpenSolaris kernel)”. Bản gốc lưu trữ ngày 6 tháng 11 năm 2019. Truy cập ngày 16 tháng 12 năm 2008. ^ “Haiku Source”. libroot.so is not part of GNU project and is included in Haiku source code. ^ Torvalds, Linus (ngày 9 tháng 1 năm 2002). “Posting to the glibc mailing list”. ^ “OpenMoko components”. 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  ?”. Question: which version of the GLIBC was used to build the Familiar 0.8.4 ? Answer: 2.3.3 Trang web chính thức